From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Yuval Avnery <yuvalav@mellanox.com>
Cc: Jiri Pirko <jiri@mellanox.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: [PATCH net-next] netdevsim: Add max_vfs to bus_dev
Date: Fri, 13 Dec 2019 10:08:28 -0800 [thread overview]
Message-ID: <20191213100828.6767de6e@cakuba.netronome.com> (raw)
In-Reply-To: <AM6PR05MB514261CD6F95F104C0353A4BC5540@AM6PR05MB5142.eurprd05.prod.outlook.com>
On Fri, 13 Dec 2019 03:21:02 +0000, Yuval Avnery wrote:
> > I see, is this a more fine grained capability or all or nothing for SR-IOV control?
> > I'd think that if the SmartNIC's eswitch just encapsulates all the frames into a
> > L4 tunnel it shouldn't care about L2 addresses.
>
> People keep saying that, but there are customers who wants this capability :)
Right, but we should have a plan for both, right? Some form of a switch
between L4/no checking/ip link changes are okay vs strict checking/L2/
SmartNIC provisions MAC addrs?
> > > > What happens if the SR-IOV host changes the MAC? Is it used by HW or
> > > > is the MAC provisioned by the control CPU used for things like spoof
> > > > check?
> > >
> > > Host shouldn't have privileges to do it.
> > > If it does, then it's under the host ownership (like in non-smartnic mode).
> >
> > I see so the MAC is fixed from bare metal host's PoV? And it has to be set
>
> Yes
>
> > through some high level cloud API (for live migration etc)?
> > Do existing software stacks like libvirt handle not being able to set the MAC
> > happily?
>
> I am not sure what you mean.
> What we are talking about here is the E-switch manager setting a MAC to another VF.
> When the VF driver loads it will query this MAC from the NIC. This is the way
> It works today with "ip link set _vf_ mac"
>
> Or in other words we are replacing "ip link set _vf_ mac" and not "ip link set address"
> So that it can work from the SmartNic embedded system.
> There is nothing really new here, ip link will not work from a SmartNic,
> this is why need devlink subdev.
Ack, but are we targeting the bare metal cloud scenario here or
something more limited? In a bare metal cloud AFAIU the customers
can use SR-IOV on the host, but the MACs need to be communicated/
/requested from the cloud management system.
IOW the ip link and the devlink APIs are in different domains of
control. Customer has access to ip link and provider has access to
devlink.
So my question is does libvirt run by the customer handle the fact
that it can't poke at ip link gracefully, and if live migration is
involved how is the customer supposed to ask the provider to move an
address?
next prev parent reply other threads:[~2019-12-13 20:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 2:58 [PATCH net-next] netdevsim: Add max_vfs to bus_dev Yuval Avnery
2019-12-11 17:58 ` Jakub Kicinski
2019-12-11 18:19 ` Yuval Avnery
2019-12-11 19:15 ` Jakub Kicinski
2019-12-11 19:57 ` Yuval Avnery
2019-12-11 22:24 ` Jakub Kicinski
2019-12-11 23:25 ` Yuval Avnery
2019-12-11 23:49 ` Jakub Kicinski
2019-12-12 5:11 ` Yuval Avnery
2019-12-12 18:25 ` Jakub Kicinski
2019-12-12 18:47 ` Ido Schimmel
2019-12-13 1:37 ` Jakub Kicinski
2019-12-12 20:44 ` Yuval Avnery
2019-12-13 1:54 ` Jakub Kicinski
2019-12-13 3:21 ` Yuval Avnery
2019-12-13 18:08 ` Jakub Kicinski [this message]
2019-12-13 20:05 ` Yuval Avnery
2019-12-16 20:44 ` Jakub Kicinski
2019-12-16 22:52 ` Yuval Avnery
2019-12-17 19:06 ` Yuval Avnery
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=20191213100828.6767de6e@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=jiri@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yuvalav@mellanox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox