From: Ilya Maximets <i.maximets@ovn.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Shahaf Shuler <shahafs@mellanox.com>,
Jerin Jacob <jerinjacobk@gmail.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
Date: Wed, 30 Oct 2019 16:07:23 +0100 [thread overview]
Message-ID: <0fd4b3fc-ec27-484d-8ed6-370fa7905eb6@ovn.org> (raw)
In-Reply-To: <20191029185051.32203-1-thomas@monjalon.net>
On 29.10.2019 19:50, Thomas Monjalon wrote:
> In a virtual environment, the network controller may have to configure
> some SR-IOV VF parameters for security reasons.
>
> When the PF (host port) is driven by DPDK (OVS-DPDK case),
> we face two different cases:
> - driver is bifurcated (Mellanox case),
> so the VF can be configured via the kernel.
> - driver is on top of UIO or VFIO, so DPDK API is required,
> and PMD-specific APIs were used.
So, what is wrong with setting VF mac via the representor port as
it done now? From our previous discussion, I thought that we concluded
that is enough to have current API, i.e. just call set_default_mac()
for a representor port and this will lead to setting mac for VF.
This is how it's implemented in Linux kernel and this is how it's
implemented in current DPDK drivers that supports setting mac for
the representor.
The only use case for this new API is to be able to control mac of
the representor itself, which doesn't make much sense. At least there
are only hypothetical use cases. And once again, Linux kernel doesn't
support this behavior.
> This new generic API will avoid vendors fragmentation.
I don't see the fragmentation. Right now you can set VF mac from DPDK
by calling set_default_mac() for representor. This API exists for all
vendors. Not implemented for Intel, but new API is not implemented too.
The this is that this new API will produce conceptual fragmentation
between DPDK and the Linux kernel, because to do the same thing you'll
have to use different ways. I mean, to change mac of VF in kernel you
need to set mac to the representor, but in DPDK changing setting mac to
representor will lead to changing the mac of the representor itself,
not the VF. This will be really confusing for users.
>
> Some PMD-specific API could migrate to this generic model.
> As an example, the default MAC address configuration is demonstrated
> for a VF mapped to mlx5 representor port.
>
> As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2.
>
> I am sorry I had not send a patch since proposing a RFC in August.
> (I gave priority to the summit and the -rc1 release)
>
>
> Thomas Monjalon (3):
> ethdev: identify SR-IOV VF from host
> ethdev: set VF MAC address from host
> net/mlx5: set VF MAC address from host
>
> drivers/net/mlx5/mlx5.c | 6 +++
> drivers/net/mlx5/mlx5.h | 1 +
> drivers/net/mlx5/mlx5_mac.c | 19 ++++++++
> lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++---
> lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++
> lib/librte_ethdev/rte_ethdev_core.h | 1 +
> lib/librte_ethdev/rte_ethdev_version.map | 1 +
> 7 files changed, 114 insertions(+), 7 deletions(-)
>
next prev parent reply other threads:[~2019-10-30 15:07 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 15:06 [dpdk-dev] [RFC] " Thomas Monjalon
2019-08-15 15:34 ` Jerin Jacob Kollanukkaran
2019-08-15 17:59 ` Thomas Monjalon
2019-08-29 15:02 ` Iremonger, Bernard
2019-09-04 8:23 ` Thomas Monjalon
2019-10-29 18:50 ` [dpdk-dev] [PATCH v2 0/3] " Thomas Monjalon
2019-10-29 18:50 ` [dpdk-dev] [PATCH v2 1/3] ethdev: identify " Thomas Monjalon
2019-10-29 18:50 ` [dpdk-dev] [PATCH v2 2/3] ethdev: set VF MAC address " Thomas Monjalon
2019-11-01 0:18 ` [dpdk-dev] [RFC PATCH] net/i[xgb|40]e: " Thomas Monjalon
2019-10-29 18:50 ` [dpdk-dev] [PATCH v2 3/3] net/mlx5: " Thomas Monjalon
2019-10-30 4:08 ` [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF " Jerin Jacob
2019-10-30 7:22 ` Shahaf Shuler
2019-10-30 9:24 ` Jerin Jacob
2019-11-01 0:24 ` Thomas Monjalon
2019-11-01 9:06 ` Ilya Maximets
2019-11-01 9:56 ` Ilya Maximets
2019-10-30 8:56 ` Thomas Monjalon
2019-10-30 9:15 ` Jerin Jacob
2019-11-01 0:33 ` Thomas Monjalon
2019-11-01 11:01 ` Jerin Jacob
2019-11-01 13:25 ` Jerin Jacob
2019-11-03 6:31 ` Shahaf Shuler
2019-10-30 15:07 ` Ilya Maximets [this message]
2019-10-30 15:49 ` Thomas Monjalon
2019-10-30 16:09 ` Ilya Maximets
2019-10-30 21:42 ` Thomas Monjalon
2019-11-01 9:32 ` Ilya Maximets
2019-11-03 6:48 ` Shahaf Shuler
2019-11-03 15:27 ` Ananyev, Konstantin
2019-11-03 22:09 ` Thomas Monjalon
2019-11-07 14:44 ` Thomas Monjalon
2019-11-04 10:28 ` Ilya Maximets
2019-11-04 14:30 ` Asaf Penso
2019-11-04 14:58 ` Ilya Maximets
2019-11-04 20:33 ` Shahaf Shuler
2019-11-05 12:15 ` Ilya Maximets
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=0fd4b3fc-ec27-484d-8ed6-370fa7905eb6@ovn.org \
--to=i.maximets@ovn.org \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerinjacobk@gmail.com \
--cc=shahafs@mellanox.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).