Pass the number of segments coalesced by LRO up the stack by repurposing the tso_segsz pkthdr field during RX processing, and use the information in TCP for more correct accounting and as a congestion control input. This is only a start, and an audit of other uses for the data is left as future work.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I can't prove my paranoia, so I think we should get this in, as it will be an improvement on balance.
| sys/netinet/tcp_lro.c | ||
|---|---|---|
| 395 ↗ | (On Diff #19458) | I have a slight twinge of paranoia that not every path that does not flow through LRO will use a properly initialized (zeroed) pkthdr mbuf, and we might see garbage in this field. |
Comment Actions
A similar-ish problem in the current LRO implementation is that it doesn't heed the TCP PSH bit and continues to aggregate frames, and the upper layers do not know how many frames with PSH bit were compressed into the LRO'd packet.