[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH] virtio-net: Add support for correct hdr_len field.
On Thu, Feb 20, 2020 at 09:51:17AM +0000, Vitaly Mireyno wrote: > > >-----Original Message----- > >From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-open.org> On Behalf Of > >Michael S. Tsirkin > >Sent: Thursday, 20 February, 2020 10:12 > >To: Vitaly Mireyno <vmireyno@marvell.com> > >Cc: virtio-comment@lists.oasis-open.org; jasowang@redhat.com > >Subject: Re: [virtio-comment] [PATCH] virtio-net: Add support for correct hdr_len field. > > > >---------------------------------------------------------------------- > >On Thu, Oct 24, 2019 at 03:24:43PM +0000, Vitaly Mireyno wrote: > >> Some devices benefit from the knowledge of the exact header length for TSO processing. > >> Add a feature bit for a driver that is capable of providing the correct header length for TSO packets. > >> > >> Signed-off-by: Vitaly Mireyno <vmireyno@marvell.com> > > > >So I looked at implementing this and maybe this was not such a good idea after all. > > > >How would we implement this in Linux? > >Current code just puts skb_headlen there which is # of bytes in the linear buffer. > >Which I guess it often the header, but not at all always. > > > >Should this have been limited to TSO packets? > > > >I also could not figure out how this is useful for the host. > >Could you enlighten me pls? > > As see it, header length is essential for TSO, and maybe not so useful for non-TSO. So maybe we should limit this for when gso type is actually set? > To calculate the header length, I suppose a Linux driver could do something like: > skb_transport_header(skb) + tcp_hdrlen(skb) - skb->data That's parsing the header in software. Why not have the card do it in hardware? -- MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]