[PATCH] mlx4_en: fix transmit of packages when blue frame is enabled

Thadeu Lima de Souza Cascardo cascardo at linux.vnet.ibm.com
Wed Oct 5 07:26:20 EST 2011


On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
> 
>  .../...
> 
> > > Can you also send me the output of ethtool -i?
> > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > > 
> > > Yevgeny
> > 
> > Hello, Yevgeny.
> > 
> > You will find the output of ethtool -i below.
> > 
> > I am copying Ben and powerpc list, in case this is an issue with Power
> > processors. They can provide us some more insight into this.
> 
> May I get some background please ? :-)
> 
> I'm not aware of a specific issue with write combining but I'd need to
> know more about what you are doing and the code to do it to comment on
> whether it should work or not.
> 
> Cheers,
> Ben.
> 
> 

Hello, Ben.

Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
added blue frame support, that does not require writing to the device
memory to indicate a new packet (the doorbell register as it is called).

Well, the ring is getting full with no interrupt or packets transmitted.
I simply added a write to the doorbell register and it works for me.
Yevgeny says this is not the right fix, claiming there is a problem with
write combining on POWER. The code uses memory barriers, so I don't know
why there is any problem.

I am posting the code here to show better what the situation is.
Yevgeny can tell more about the device and the driver.

The code below is the driver as of now, including a diff with what I
changed and had resulted OK for me. Before the blue frame support, the
only code executed was the else part. I can't tell much what the device
should be seeing and doing after the blue frame part of the code is
executed. But it does send the packet if I write to the doorbell
register.

Yevgeny, can you tell us what the device should be doing and why you
think this is a problem on POWER? Is it possible that this is simply a
problem with the firmware version?

Thanks,
Cascardo.

---
        if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tag) {
                *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
ring->doorbell_qpn;
                op_own |= htonl((bf_index & 0xffff) << 8);
                /* Ensure new descirptor hits memory
                * before setting ownership of this descriptor to HW */
                wmb();
                tx_desc->ctrl.owner_opcode = op_own;

                wmb();

                mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
long *) &tx_desc->ctrl,
                     desc_size);

                wmb();

                ring->bf.offset ^= ring->bf.buf_size;
        } else {
                /* Ensure new descirptor hits memory
                * before setting ownership of this descriptor to HW */
                wmb();
                tx_desc->ctrl.owner_opcode = op_own;
-               wmb();
-               writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
        }

+       wmb();
+       writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
+
---



More information about the Linuxppc-dev mailing list