> > data: 1634 frags: 1408 4096 4096 4096 2108 4
> >
> > Is there a reason why the remaining 1408 bytes cant be stuffed into
> > skb->data? Or is that an issue with MTU sized buffers?
>
> The reason is that the skb has to accomodate other things like
> headers and skb_shared_info. It seems to have added up to a
> quite considerable value in your case.
>
> Perhaps sendmsg should check whether the data can fit in the space
> available in skb->data, and if not just go for a fragment right away.
Originally I thought we could save ourselves a fragment. However
thinking about it more we will always have at least the headers in
skb->data. If so there isnt much to gain by spilling into the fragment
straight away. Or am I wrong?
> This is understandable. You really need to have a rcv window that's
> much bigger than 64K to have any chance of filling up the TSO packet
> with tcp_tso_win_divisor set to 8.
That makes sense.
> BTW, how did you measure the gains?
The TSO gains? On older 2.6 the TSO gain was easy to see on a web
benchmark. On recent kernels it isnt, but we havent tested a divisor
of 4 or 2 yet.
Im interested if the divisor of 8 was based on some testing, or if we
can tune the default a bit. It would be nice for TSO to kick in on
normal workloads (like web serving).
Anton
|