Add driver backpressure

[kmacy]

Summary

Rather than treating a transient txq overrun as a network loss event schedule another call to tcp_output when the software ring has partially drained.

[hiren]

@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.

[kmacy]

In D4295#90451, @hiren wrote:

@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.

It's not part of HEAD yet. The objective here is to elucidate the mechanism. I haven't been able to test it under real load yet. Do you really want to run with scissors? :D

[sbruno]

I'm adding a "looks good to me" here for the Intel Reviewers as this adds functionality in the stack and the modification to the driver is required.

[hiren]

In D4295#90577, @kmacy wrote:

In D4295#90451, @hiren wrote:

@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.

It's not part of HEAD yet. The objective here is to elucidate the mechanism. I haven't been able to test it under real load yet. Do you really want to run with scissors? :D

Heh, as we talked on the transport call, we can reproduce this problem and would love to see how the patch is handling it. :-)

I'd let others chime-in wrt design and what not.

[cramerj_intel.com]

Does ixgbe compile with the first parenthesis missing?

[kmacy]

In D4295#127591, @cramerj_intel.com wrote:

Does ixgbe compile with the first parenthesis missing?

Odd. I'll update the patch. Thanks.

-M

[gallatin]

Why is this re-surfacing?

I think the ratelimit code has a better solution, since TCP can query how full the nic queue is and avoid ENOBUFs entirely by avoiding sending on a full queue. The problem with doing this in general is that, outside of ratelimit, the TCP stack has no way to determine what NIC queue a packet will be sent on.

[kbowling]

In D4295#1077477, @gallatin wrote:

Why is this re-surfacing?

I think the ratelimit code has a better solution, since TCP can query how full the nic queue is and avoid ENOBUFs entirely by avoiding sending on a full queue. The problem with doing this in general is that, outside of ratelimit, the TCP stack has no way to determine what NIC queue a packet will be sent on.

Hi Drew, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386