netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Jiri Benc <jbenc@redhat.com>, Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, Thomas Graf <tgraf@suug.ch>,
	Roopa Prabhu <roopa@cumulusnetworks.com>,
	ogerlitz@mellanox.com, John Fastabend <john.fastabend@gmail.com>,
	sridhar.samudrala@intel.com, ast@kernel.org,
	daniel@iogearbox.net, simon.horman@netronome.com,
	Paolo Abeni <pabeni@redhat.com>,
	Pravin B Shelar <pshelar@nicira.com>,
	hannes@stressinduktion.org, kubakici@wp.pl
Subject: Re: [RFC] net: store port/representative id in metadata_dst
Date: Fri, 23 Sep 2016 13:55:12 +0100	[thread overview]
Message-ID: <20160923135512.64e5d5e9@jkicinski-Precision-T1700> (raw)
In-Reply-To: <20160923110609.2f221f99@griffin>

On Fri, 23 Sep 2016 11:06:09 +0200, Jiri Benc wrote:
> On Fri, 23 Sep 2016 08:34:29 +0200, Jiri Pirko wrote:
> > So if I understand that correctly, this would need some "shared netdev"
> > which would effectively serve only as a sink for all port netdevices to
> > tx packets to. On RX, this would be completely avoided. This lower
> > device looks like half zombie to me.  
> 
> Looks more like a quarter zombie. Even tx would not be allowed unless
> going through one of the ports, as all skbs without
> METADATA_HW_PORT_MUX metadata_dst would be dropped. But it would be
> possible to attach qdisc to the "lower" netdevice and it would actually
> have an effect. On rx this netdevice would be ignored completely. This
> is very weird behavior.
> 
> > I don't like it :( I wonder if the
> > solution would not be possible without this lower netdev.  
> 
> I agree. This approach doesn't sound correct. The skbs should not be
> requeued.

Thanks for the responses!

I think SR-IOV NICs are coming at this problem from a different angle,
we already have a big, feature-full per-port netdevs and now we want to
spawn representators for VFs to handle fallback traffic.  This patch
would help us mux VFR traffic on all the queues of the physical port
netdevs (the ones which were already present in legacy mode, that's the
lower device).

I read the mlxsw code when I was thinking about this and I wasn't
100% comfortable with returning NETDEV_TX_BUSY, I thought this
behaviour should be generally avoided.  (BTW a very lame question - does
mlxsw ever stop the queues?  AFAICS it only returns BUSY, isn't that
confusing to the stack?)

FWIW the switchdev SR-IOV model we have now seems to be to treat the
existing netdevs as "MAC ports" and spawn representatives for VFs but
not represent PFs in any way.  This makes it impossible to install
VF-PF flow rules.  I worry this can bite us later but that's slightly
different discussion :)  For the purpose of this patch please assume
the lower dev is the MAC/physical/external port.

  reply	other threads:[~2016-09-23 12:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 19:26 [RFC] net: store port/representative id in metadata_dst Jakub Kicinski
2016-09-23  6:34 ` Jiri Pirko
2016-09-23  9:06   ` Jiri Benc
2016-09-23 12:55     ` Jakub Kicinski [this message]
2016-09-23 14:23       ` John Fastabend
2016-09-23 15:29         ` Jakub Kicinski
2016-09-23 17:22           ` Samudrala, Sridhar
2016-09-23 20:17             ` Jakub Kicinski
2016-09-23 20:25               ` John Fastabend
2016-09-23 20:45                 ` Jakub Kicinski
2016-09-23 21:20                   ` John Fastabend
2016-09-29 11:10                     ` Jakub Kicinski

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=20160923135512.64e5d5e9@jkicinski-Precision-T1700 \
    --to=jakub.kicinski@netronome.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hannes@stressinduktion.org \
    --cc=jbenc@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=john.fastabend@gmail.com \
    --cc=kubakici@wp.pl \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=pabeni@redhat.com \
    --cc=pshelar@nicira.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=simon.horman@netronome.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=tgraf@suug.ch \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).