Re: [PATCH] virtio-net: introduce TSO limit feature

On Thu, Oct 16, 2025 at 2:19 PM Michael S. Tsirkin <[email protected]> wrote:
>
> On Thu, Oct 16, 2025 at 01:46:58PM +0800, Jason Wang wrote:
> > On Wed, Oct 15, 2025 at 3:02 PM Michael S. Tsirkin <[email protected]> wrote:
> > >
> > > On Wed, Oct 15, 2025 at 12:29:13PM +0800, Jason Wang wrote:
> > > > On Tue, Oct 14, 2025 at 4:59 PM Michael S. Tsirkin <[email protected]> wrote:
> > > > >
> > > > > thanks for the patch! yet something to improve.
> > > > > I note issues only when encountered 1st time but please
> > > > > do go and check all patch for each issue.
> > > > >
> > > > >
> > > > > On Tue, Oct 14, 2025 at 12:22:43PM +0800, Jason Wang wrote:
> > > > > > This patch introduces TSO limit feature which allows the device to
> > > > > > advertise:
> > > > > >
> > > > > > - Maximum TCP length of a TSO packet or inner TSO packet when UDP
> > > > > >   tunnel is support
> > > > > > - Maximum number of segment that can be produced by the device after
> > > > > >   segmentation of TSO or inner TSO packet of a UDP tunnel
> > > > > >
> > > > > > This is a must to implement TCP jumbogram, as networking stack needs
> > > > > > to know the limitation of the device in order to produce TSO packet as
> > > > > > large as possible.
> > >
> > >
> > > Maybe you can provide an overview of how this all is used?
> >
> > Sure, this feature does not implement BIG TCP (jumbogram) itself. BIG
> > TCP requires a little bit more to be implemented:
> >
> > 1) new gso_type for jumbogram
> > 2) when TCP length exceeds 64K, we should mandate ip->tot_len to be
> > zero and device can judge from the length of the buffer
> > 3) other stuffs
> >
> > I guess this is something that Viet wants to work on.
> >
> > But before BIG TCP, the driver needs to know the device limitation of
> > TSO packets. That is what this patch did. BIG TCP is not the only
> > user, it could be used in the software datapath as well. Consider a
> > simple datapath:
> >
> > virtio-net -> TAP -> bridge -> eth0
> >
> > If eth0's tso_max_size is less than 64K, we need to advertise this to
> > virtio-net otherwise 64K gso packets will be segmented by software run
> > xmit in eth0. We've encountered this in collaboration with mana and
> > virtio-net/vhost.
>
>
> Wait a second this does not make any sense. Bridge disables tso,
> it only works with gso.
>

I don't understand here, we have used similar setups for a very long
time and TSO works well?

Maybe my statement is not clear enough, I meant the forwarding path of
the bridge.

>
> So what is the actual motivation?

Thanks


>
> > > I am looking at tcp_fragment and I just do not see
> > > where it looks at any device limits.
> > >
> >
> > It works like a device advertising tso_max_size/segs, and it is capped
> > by gso_max_size/segs. The gso_max_size/segs were the ones that are
> > used by the stack to determine the skb->len.
> >
> > Thanks
> >
> > > --
> > > MST
> > >
>