tso with vlan

[Thor Simon]

Hi Thor,
good news on the tso counter - it shows that offload was working.
Bad news - I added the vlan on top and reran ttcp with tso4 enabled on
the underlying wm and got no movement on the tso counter. Also I
can't set tso4 on the vlan interface.

[carboned to tech-net]

I'm not surprised. The double-handling of M_CSUM_TSOv4 has to be causing
this -- unlike plain checksum offload, which is always deferred, as we
noticed tcp_output doesn't try to defer segmentation unless it thinks it
will work -- unless the interface capabilities on what it thinks will be
the output interace say it is supported and enabled.

I think this is a bug. I think has_tso should be removed from tcp_output
and use_tso should default to 1 -- in the specific cases where TSO can't
be used, tcp_output _already_ explicitly sets use_tso to 0. Just like
checksum offload, the software TSO "offload" code (tcp4_segment etc.)
should catch the M_CSUM_TSOv4 mbufs and do the right thing.

The thing is, right now I don't think the software segmentation "offload"
is ever used, or if it is, only for packets that were already in-flight
through the stack when the interface capabilities were changed with ifconfig
(I wonder if this can actually happen). I wonder if it works!

[YAMAMOTO Takashi]

hi,

Post by Thor Simon

Hi Thor,
good news on the tso counter - it shows that offload was working.
Bad news - I added the vlan on top and reran ttcp with tso4 enabled on
the underlying wm and got no movement on the tso counter. Also I
can't set tso4 on the vlan interface.

[carboned to tech-net]
I'm not surprised. The double-handling of M_CSUM_TSOv4 has to be causing
this -- unlike plain checksum offload, which is always deferred, as we
noticed tcp_output doesn't try to defer segmentation unless it thinks it
will work -- unless the interface capabilities on what it thinks will be
the output interace say it is supported and enabled.
I think this is a bug. I think has_tso should be removed from tcp_output
and use_tso should default to 1 -- in the specific cases where TSO can't
be used, tcp_output _already_ explicitly sets use_tso to 0. Just like
checksum offload, the software TSO "offload" code (tcp4_segment etc.)
should catch the M_CSUM_TSOv4 mbufs and do the right thing.
The thing is, right now I don't think the software segmentation "offload"
is ever used, or if it is, only for packets that were already in-flight
through the stack when the interface capabilities were changed with ifconfig
(I wonder if this can actually happen). I wonder if it works!

it's actually used eg. when a packet filter redirect packets.
i tested the code when i implemented it.
i left the has_tso check because i saw negative performace effects
when i tested.

YAMAMOTO Takashi

Post by Thor Simon
--
Thor Lancelot Simon
Millerton, NY, USA

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by YAMAMOTO Takashi
it's actually used eg. when a packet filter redirect packets.
i tested the code when i implemented it.
i left the has_tso check because i saw negative performace effects
when i tested.

Thanks! I wondered about that (as well as how well tested the software
"offload" code was) or I would probably have just checked in the change
to remove has_tso -- it does seem to work that way, but I didn't do
extensive performance testing on platforms without TSO, or any
correctness testing beyong a couple of quick ttcp and tcpdump runs.

It's unfortunate how complex the has_tso/use_tso logic is, though.
Maybe if we can eventually better modularize SACK and congestion
control, and get some of those IPSEC ifdefs out of there, it will be
easier to read and understand.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Masao Uebayashi]

Post by Thor Lancelot Simon
It's unfortunate how complex the has_tso/use_tso logic is, though.
Maybe if we can eventually better modularize SACK and congestion
control, and get some of those IPSEC ifdefs out of there, it will be
easier to read and understand.

I'm not familar with network stack, but I just want to express that I'm not
a big fan of the current SACK code too. Such a big addition of complexity
should be avoided IMHO.

Masao

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de