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

[Michael Tuexen]

On Dec 7, 2013, at 12:25 AM, Adrian Chadd <adrian at freebsd.org> wrote:

> On 6 December 2013 13:10, Michael Tuexen
> <Michael.Tuexen at lurchi.franken.de> wrote:
> 
>> 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.
> 
> We're heading down the right path.
> 
> I'm increasingly believing that ignoring the return value is the
> correct thing to do.
You mean ignoring the return value transport layer? Why not provide
a return code which can be used? Returning a value which needs to
be ignored doesn't make a lot of sense to me...

I think if_transmit() should only return an error if there was a problem
with the provided packet, not with some packet, probably a different one.
Can you point me to a consumer of the return code of if_transmit(),
which can benefit from the logic you described?

Best regards
Michael
> 
> 
> -adrian
>