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

[Michael Tuexen]

On Dec 6, 2013, at 9:20 PM, John-Mark Gurney <jmg at funkthat.com> wrote:

> 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...
Well, this is what happens:
The sender takes a packet from the send-queue, calls ip-output. Since
it returns an error, we don't move it to the sent-queue, but leave
it in the send queue (assuming it doesn't went on the wire).
However, the driver puts it on the wire, it makes it to the peer,
the peer sends SACK, and we receive the SACK. Since the packet is
not on the sent queue, we don't realize that it is acked. Receiving
a SACK is a trigger for sending a packet. So we take the next one
from the send-queue (the one from the beginning), and send it again.
So it is a wire speed ping pong...
So in case the lower layer tells us that there was a problem in
sending the packet, we
* don't consider it sent
* wait for the next normal protocol trigger for send another packet.
This sounds OK to me...

That is why I need to know what an error from ip_output() means.
If I can't conclude that the provided packet was dropped, I can just
consider it sent and don't try to do any optimisation.

Best regards
Michael
> 
> -- 
>  John-Mark Gurney				Voice: +1 415 225 5579
> 
>     "All that I will do, has been done, All that I have, has not."
>