All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: "Björn Töpel" <bjorn.topel@gmail.com>, bpf <bpf@vger.kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	Netdev <netdev@vger.kernel.org>,
	"Karlsson, Magnus" <magnus.karlsson@intel.com>
Subject: Re: [PATCH bpf] xsk: mark napi_id on sendmsg()
Date: Thu, 30 Jun 2022 08:52:52 -0700	[thread overview]
Message-ID: <20220630085252.51e29049@kernel.org> (raw)
In-Reply-To: <Yr2Op9m1xt5gW7Pw@boxer>

On Thu, 30 Jun 2022 13:53:11 +0200 Maciej Fijalkowski wrote:
> > > Would it be possible to move the marking to when the queue is getting
> > > bound instead of the recv/send paths?   
> > 
> > I mean when socket is getting bound.  
> 
> So Bjorn said that it was the design choice to follow the standard
> sockets' approach. I'm including a dirty diff for a discussion which
> allows me to get napi_id at bind() time. But, this works for ice as this
> driver during the XDP prog/XSK pool load only disables the NAPI, so we are
> sure that napi_id stays the same. That might not be the case for other
> AF_XDP ZC enabled drivers though, they might delete the NAPI and this
> approach wouldn't work...or am I missing something?

Possible, but IDK if we're changing anything substantially in that
regard. The existing code already uses sk_mark_napi_id_once() so
if the NAPI ID changes during the lifetime of the socket the user
will be out of luck already. But no strong feelings.

> I'd prefer the diff below though as it simplifies the data path, but I
> can't say if it's safe to do so. We would have to be sure about drivers
> keeping their NAPI struct. This would also allow us to drop napi_id from
> xdp_rxq_info.


  reply	other threads:[~2022-06-30 15:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 10:57 [PATCH bpf] xsk: mark napi_id on sendmsg() Maciej Fijalkowski
2022-06-29 12:45 ` Björn Töpel
2022-06-29 12:53   ` Maciej Fijalkowski
2022-06-29 13:18     ` Magnus Karlsson
2022-06-29 16:16     ` Jakub Kicinski
2022-06-29 16:17       ` Jakub Kicinski
2022-06-30 11:53         ` Maciej Fijalkowski
2022-06-30 15:52           ` Jakub Kicinski [this message]
2022-06-29 13:39   ` Björn Töpel
2022-06-29 14:28     ` Maciej Fijalkowski

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=20220630085252.51e29049@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    /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.