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

Authored by sepherosa_gmail.com on Mar 21 2016, 8:53 AM.

Details

Reviewers

gallatin
howard0su_gmail.com
honzhan_microsoft.com
decui_microsoft.com
• hselasky
np
delphij
adrian

Group Reviewers

network
transport

Commits

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

Summary

So that callers could react accordingly.

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

sepherosa_gmail.com updated this revision to Diff 14472.Mar 21 2016, 8:53 AM

sepherosa_gmail.com retitled this revision from to tcp/lro: Return TCP_LRO_NO_ENTRIES if we are short of LRO entries..

sepherosa_gmail.com updated this object.

sepherosa_gmail.com edited the test plan for this revision. (Show Details)

sepherosa_gmail.com added reviewers: network, gallatin, np, • hselasky, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com.

Herald added a reviewer: transport. · View Herald TranscriptMar 21 2016, 8:53 AM

I have no objection.

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

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.

Closed by commit rS297265: tcp/lro: Return TCP_LRO_NO_ENTRIES if we are short of LRO entries. (authored by sephe). · Explain WhyMar 25 2016, 2:54 AM

This revision was automatically updated to reflect the committed changes.