tcp/lro: Return TCP_LRO_NO_ENTRIES if we are short of LRO entries.

[sepherosa_gmail.com]

Summary

So that callers could react accordingly.

[gallatin]

I have no objection.

However, if you can use the RSS-sorted LRO lro_queue_mbuf() interface, then this should never be a problem.

[sepherosa_gmail.com]

In D5695#122308, @gallatin wrote:

I have no objection.

However, if you can use the RSS-sorted LRO lro_queue_mbuf() interface, then this should never be a problem.

The difficult part is to pick up a proper mbuf limit, so that we can aggregate "just enough segments/ACKs" per connection under various loads. In the Hyper-V, aggregating too many segments will cause problem like ACK's timeliness, but aggregating not enough segments will waste precious cpu time (virtual cpu is slow).

Well, at least returning a different value does hurt here :)

I plan to commit it tomorrow.