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

[Adrian Chadd]

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.


-adrian