DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Jerin Jacob <jerinjacobk@gmail.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
Date: Wed, 30 Oct 2019 07:22:53 +0000	[thread overview]
Message-ID: <AM0PR0502MB3795D75CF2A3B8C5DCA82BD2C3600@AM0PR0502MB3795.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1NsQpqoAeQnqG3s2iFDZA+Qc8N1H2n14UD_gdyZ3rhr0A@mail.gmail.com>

Wednesday, October 30, 2019 6:09 AM, Jerin Jacob:
> Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from
> host
> 
> On Wed, Oct 30, 2019 at 12:21 AM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> >
> > In a virtual environment, the network controller may have to configure
> > some SR-IOV VF parameters for security reasons.
> 
> Just to understand, Could you explain more details/examples 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,
> 
> Not true. Both UIO and VFIO are NOT allowed to create SRIOV VF from the
> PF device.
> It is only allowed through igb-uio out of tree driver without iommu support.

Per my understanding Thomas proposal is not to create the VFs from the PF device. it is to configure their network attributes from the PF after they have been created.

> 
> 
> >       and PMD-specific APIs were used.
> > This new generic API will avoid vendors fragmentation.
> 
> The API is good. But I have concerns about the vendor implementation of
> this API.
> It can support only vendors with bifurcated driver(Mellanox case).
> or using igb_uio(non iommu case) but not the devices with VFIO(Which is the
> first-class citizen).
> 
> All the control plane control stuff to replace Linux with "port representor"
> logic will be of the mercy  of an "out of tree" driver either with igb_uio or
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F58810%2F&amp;data=02%7C01%7Cshahafs%40mel
> lanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637080053397844419&amp;sdata=sAIRqTnAN
> G8lIb2eYhvcylU%2F6%2F81eXPDeGbnrUdMnis%3D&amp;reserved=0

I am not sure I follow. 
Device that supports representor should enable the HV to configure their macs. It is the best if it can allow it using the in-tree drivers (VFIO, Mellanox bifurcated..) by using, for example, so device registers on the device bar. 
Otherwise such vendor will need to recommend its customers to use other, out of tree, driver to get the needed functionality to enable switchdev and representors. 

> 
> I am _not against_ on DPDK supports port representor or controlling netdev
> VF traffic, but if we have taken that path then DPDK should have the
> infrastructure to support for all driver models like VFIO(Addressed in [1])
> 
> I would have this question when DPDK starts supporting port
> representor(but I was not aware that kernel security issue on netdev ports
> controlled by DPDK in non-bifurcated driver case and concise effort block
> such scheme by kernel [2])
> 
> 
>  [1]
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F58810%2F&amp;data=02%7C01%7Cshahafs%40mel
> lanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637080053397844419&amp;sdata=sAIRqTnAN
> G8lIb2eYhvcylU%2F6%2F81eXPDeGbnrUdMnis%3D&amp;reserved=0
> [2]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fpatch%2F10522381%2F&amp;data=02%7C01%7Cshahafs
> %40mellanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e
> 4d9ba6a4d149256f461b%7C0%7C0%7C637080053397844419&amp;sdata=fyEo
> fHJQM51L8ssvLNyaLwrsCK8bBJiuPT%2FgMje3QxE%3D&amp;reserved=0
> 
> 
> 
> >
> > 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(-)
> >
> > --
> > 2.23.0
> >

  reply	other threads:[~2019-10-30  7:22 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 [this message]
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
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=AM0PR0502MB3795D75CF2A3B8C5DCA82BD2C3600@AM0PR0502MB3795.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinjacobk@gmail.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).