All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH net] net/packet: tpacket_rcv: do not increment ring index on drop
Date: Wed, 11 Mar 2020 17:25:33 -0400	[thread overview]
Message-ID: <20200311171634-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CA+FuTSft5pSf7YJW1Ws=P7rYjWiwmZ6edYDPi7DVBafDWqcy-g@mail.gmail.com>

On Wed, Mar 11, 2020 at 10:31:47AM -0400, Willem de Bruijn wrote:
> I would expect packet sockets to behave the same with and without
> po->has_vnet_hdr. Without, they already pass all GSO packets up to
> userspace as is. Which is essential for debugging with tcpdump or
> wirehark. I always interpreted has_vnet_hdr as just an option to
> receive more metadata along, akin to PACKET_AUXDATA. Not something
> that subtly changes the packet flow.
>

So again just making sure:

	we are talking about a hypothetical case where we add a GSO type,
	then a hypothetical userspace that does not know about a specific GSO
	type, right?

I feel if someone writes a program with packet sockets, it is
important that it keeps working, and that means keep seeing
all packets, even if someone runs it on a new kernel
with a new optimization like gso. I feel dropping packets is
worse than changing gso type.

And that in turn means userspace must opt in to
seeing new GSO type, and old userspace must see old ones.

One way to do that would be converting packets on the socket, another
would be disabling the new GSO automatically as the socket is created
unless it opts in.

> That was my intend, but I only extended it to tpacket_rcv. Reading up
> on the original feature that was added for packet_rcv, it does mention
> "allows GSO/checksum offload to be enabled when using raw socket
> backend with virtio_net". I don't know what that raw socket back-end
> with virtio-net is. Something deprecated, but possibly still in use
> somewhere?

Pretty much. E.g. I still sometimes use it with an out of tree QEMU
patch - maybe I'll try to re-post it there just so we have an upstream
way to test the interface.

-- 
MST


  reply	other threads:[~2020-03-11 21:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 15:34 [PATCH net] net/packet: tpacket_rcv: do not increment ring index on drop Willem de Bruijn
2020-03-09 15:42 ` Willem de Bruijn
2020-03-09 15:50   ` Willem de Bruijn
2020-03-10  6:46     ` Michael S. Tsirkin
2020-03-10  6:43 ` Michael S. Tsirkin
2020-03-10 12:49   ` Willem de Bruijn
2020-03-10 12:59     ` Michael S. Tsirkin
2020-03-10 14:16       ` Willem de Bruijn
2020-03-10 14:43         ` Michael S. Tsirkin
2020-03-10 15:38           ` Willem de Bruijn
2020-03-10 16:14             ` Willem de Bruijn
2020-03-10 21:29             ` Michael S. Tsirkin
2020-03-10 21:35               ` Willem de Bruijn
2020-03-10 21:57                 ` Michael S. Tsirkin
2020-03-10 23:13                   ` Willem de Bruijn
2020-03-11  7:56                     ` Michael S. Tsirkin
2020-03-11 14:31                       ` Willem de Bruijn
2020-03-11 21:25                         ` Michael S. Tsirkin [this message]
2020-03-11 21:49                           ` Willem de Bruijn
2020-03-12  6:13 ` David Miller
2020-03-12  6:27   ` Michael S. Tsirkin

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=20200311171634-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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.