All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Maxim Mikityanskiy <maximmi@mellanox.com>,
	Mike Pattrick <mpattric@redhat.com>,
	netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	virtualization@lists.linux-foundation.org,
	Balazs Nemeth <bnemeth@redhat.com>,
	Flavio Leitner <fbl@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH net 1/2] net/af_packet: adjust network header position for VLAN tagged packets
Date: Wed, 20 Apr 2022 08:59:58 +0800	[thread overview]
Message-ID: <Yl9bDrDFZhc04MiY@Laptop-X1> (raw)
In-Reply-To: <20220419101325-mutt-send-email-mst@kernel.org>

On Tue, Apr 19, 2022 at 10:26:09AM -0400, Michael S. Tsirkin wrote:
> > > There are also some duplicated codes in these *_snd functions.
> > > I think we can move them out to one single function.
> > 
> > Please don't refactor this code. It will complicate future backports
> > of stable fixes.
> 
> Hmm I don't know offhand which duplication this refers to specifically
> so maybe it's not worth addressing specifically but generally not
> cleaning up code just because of backports seems wrong ...

Yes, packet_snd() and tpacket_snd() share same addr/msg checking logic that
I think we can clean up.

> > > > stretching the definition of the flags to include VLAN is acceptable
> > > > (unlike outright tunnels), but even then I would suggest for net-next.
> > >
> > > As I asked, I'm not familiar with virtio code. Do you think if I should
> > > add a new VIRTIO_NET_HDR_GSO_VLAN flag? It's only a L2 flag without any L3
> > > info. If I add something like VIRTIO_NET_HDR_GSO_VLAN_TCPV4/TCPV6/UDP. That
> > > would add more combinations. Which doesn't like a good idea.
> > 
> > I would prefer a new flag to denote this type, so that we can be
> > strict and only change the datapath for packets that have this flag
> > set (and thus express the intent).
> > 
> > But the VIRTIO_NET_HDR types are defined in the virtio spec. The
> > maintainers should probably chime in.
> 
> Yes, it's a UAPI extension, not to be done lightly. In this case IIUC
> gso_type in the header is only u8 - 8 bits and 5 of these are already
> used.  So I don't think the virtio TC will be all that happy to burn up
> a bit unless a clear benefit can be demonstrated. 
> 
> I agree with the net-next proposal, I think it's more a feature than a
> bugfix. In particular I think a Fixes tag can also be dropped in that
> IIUC GSO for vlan packets didn't work even before that commit - right?

Right. virtio_net_hdr GSO with vlan doesn't work before.
I will post this to net-next.

Thanks
Hangbin

  reply	other threads:[~2022-04-20  1:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18  4:43 [PATCH net 0/2] net: fix kernel dropping GSO tagged packets Hangbin Liu
2022-04-18  4:43 ` [PATCH net 1/2] net/af_packet: adjust network header position for VLAN " Hangbin Liu
2022-04-18 15:38   ` Willem de Bruijn
2022-04-18 15:38     ` Willem de Bruijn
2022-04-19  3:02     ` Hangbin Liu
2022-04-19 13:56       ` Willem de Bruijn
2022-04-19 13:56         ` Willem de Bruijn
2022-04-19 14:26         ` Michael S. Tsirkin
2022-04-19 14:26           ` Michael S. Tsirkin
2022-04-20  0:59           ` Hangbin Liu [this message]
2022-04-20  2:47             ` Jason Wang
2022-04-20  2:47               ` Jason Wang
2022-04-18  4:43 ` [PATCH net 2/2] virtio_net: check L3 protocol for VLAN packets Hangbin Liu
2022-04-18 15:40   ` Willem de Bruijn
2022-04-18 15:40     ` Willem de Bruijn
2022-04-19  3:14     ` Hangbin Liu
2022-04-19 13:52       ` Willem de Bruijn
2022-04-19 13:52         ` Willem de Bruijn
2022-04-20  1:11         ` Hangbin Liu
2022-04-20 13:12           ` Willem de Bruijn
2022-04-20 13:12             ` Willem de Bruijn
2022-04-18  5:48 ` [PATCH net 0/2] net: fix kernel dropping GSO tagged packets Hangbin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yl9bDrDFZhc04MiY@Laptop-X1 \
    --to=liuhangbin@gmail.com \
    --cc=bnemeth@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fbl@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=maximmi@mellanox.com \
    --cc=mpattric@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.