A small fix for if_em.c, if_igb.c, if_ixgbe.c

[John-Mark Gurney]

Michael Tuexen wrote this message on Fri, Dec 06, 2013 at 21:17 +0100:
> On Dec 5, 2013, at 11:37 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> 
> > Adrian Chadd wrote this message on Thu, Dec 05, 2013 at 14:01 -0800:
> >> On 5 December 2013 13:05, Michael Tuexen
> >> <Michael.Tuexen at lurchi.franken.de> wrote:
> >> 
> >>> Just to be clear: This would mean that xxx_transmit() would return
> >>> an error even if the packet provided in the call xxx_transmit() is
> >>> enqueued and not dropped?
> >>> This would also be problem with the current SCTP stack.
> >> 
> >> I think it'll return an error only if:
> >> 
> >> * it queued the frame to the tail of the drbd;
> >> * it then tried to transmit a frame from the head of the drbd;
> >> * it failed to transmit the first frame in the drbd and it couldn't
> >> put it back into the queue for whatever reason.
> >> 
> >> So I think it should be "ok enough" for both TCP and SCTP.
> > 
> > IMO it should only return an error if the specific frame failed to be
> > sent or queued.  If you cannot determine at return time if the frame
> > failed to be transmitted/queued, then it should return success.
> Yes, this is exactly what I think too. This is what my first patch
> realizes.
> > 
> > In the above case, if there were other frames queued ahead, and the
> > first one failed, then it sounds like the frame may eventually be sent
> > and we will end up sending a duplicate frame.
> Correct. SCTP will consider the frame even unsent... So the SCTP stack
> behaves strange and sends a packet at wirespeed over and over again (which
> is not good...).

Sounds like a bug in SCTP, if it gets an error like that, it needs to back
off a bit.. Though when to wake up, etc, is harder to decide...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."