All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: brouer@redhat.com, Saeed Mahameed <saeedm@mellanox.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"sthemmin@microsoft.com" <sthemmin@microsoft.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] net: core: support XDP generic on stacked devices.
Date: Fri, 24 May 2019 12:07:15 +0200	[thread overview]
Message-ID: <20190524120715.6f1c13bd@carbon> (raw)
In-Reply-To: <ebf12468-504c-fae7-b62d-2b6db47391f9@redhat.com>

On Fri, 24 May 2019 12:17:27 +0800
Jason Wang <jasowang@redhat.com> wrote:

> > Maybe this is acceptable, but it should be documented, as the current
> > assumption dictates: XDP program runs on the core where the XDP
> > frame/SKB was first seen.  
> 
> 
> At lest for TUN, this is not true. XDP frames were built by vhost_net 
> and passed to TUN. There's no guarantee that vhost_net kthread won't 
> move to another core.

This sound a little scary, as we depend on per-CPU variables (e.g.
bpf_redirect_info).  Can the vhost_net kthread move between CPUs
within/during the NAPI-poll?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2019-05-24 10:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 17:54 [PATCH v3 0/2] XDP generic fixes Stephen Hemminger
2019-05-23 17:54 ` [PATCH v3 1/2] netvsc: unshare skb in VF rx handler Stephen Hemminger
2019-05-23 17:54 ` [PATCH v3 2/2] net: core: support XDP generic on stacked devices Stephen Hemminger
2019-05-23 19:19   ` Saeed Mahameed
2019-05-23 20:15     ` Stephen Hemminger
2019-05-24  9:33       ` Jesper Dangaard Brouer
2019-05-24 13:25         ` Jason Wang
2019-05-24  4:17     ` Jason Wang
2019-05-24 10:07       ` Jesper Dangaard Brouer [this message]
2019-05-24 13:06         ` Jason Wang
2019-05-27  4:29   ` David Miller

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=20190524120715.6f1c13bd@carbon \
    --to=brouer@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=stephen@networkplumber.org \
    --cc=sthemmin@microsoft.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.