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

[Michael Tuexen]

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...).

Best regards
Michael
> 
>> Give it a go and let me know how it goes.
>> 
>> It's an interesting architectural problem to completely solve.
> 
> -- 
>  John-Mark Gurney				Voice: +1 415 225 5579
> 
>     "All that I will do, has been done, All that I have, has not."
>