From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Ferruh Yigit <ferruh.yigit@intel.com>, 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 09:56:11 +0100 [thread overview]
Message-ID: <4976847.S65dXbhd2F@xps> (raw)
In-Reply-To: <CALBAE1NsQpqoAeQnqG3s2iFDZA+Qc8N1H2n14UD_gdyZ3rhr0A@mail.gmail.com>
30/10/2019 05:08, Jerin Jacob:
> 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?
Examples are setting the MAC address or the promiscuous mode.
These settings should be decided by the hypervisor,
and not freely set by the VM.
> > 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.
Not sure I said the contrary.
igb_uio and vfio_pf are 2 implementations of UIO and VFIO.
> > 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).
Why not? (see above)
The API is agnostic to the kernel driver in use.
> 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 http://patches.dpdk.org/patch/58810/
>
> 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]
> http://patches.dpdk.org/patch/58810/
> [2]
> https://patchwork.kernel.org/patch/10522381/
I feel you are using this thread to promote your vfio_pf implementation.
But this API and the kernel module are orthogonals.
Please can we focus on the DPDK API in this thread,
and talk about VFIO implementation in the other thread?
next prev parent reply other threads:[~2019-10-30 8:56 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 [this message]
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=4976847.S65dXbhd2F@xps \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerinjacobk@gmail.com \
--cc=stephen@networkplumber.org \
/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).