Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host

[Thomas Monjalon <thomas@monjalon.net>]

30/10/2019 10:15, Jerin Jacob:
> On Wed, Oct 30, 2019 at 2:26 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 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.
> 
> What is hypervisor here, rte_flow based DPDK application over using
> port representor?

Yes, something like that. An example is OpenStack/OVS.

> > > > 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.
> 
> Yes. I am saying without out of tree module it is not possible.
> 
> > > >       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.
> 
> My question is how do you enable in DPDK with VFIO if DPDK is giving
> this feature?

I didn't get your question.
If it is the same question as before, I think you can create the VF
before binding the PF to VFIO.

> > > 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.
> 
> Yes. I am. Because, I need to think, How I can enable this API with VFIO.
> Otherwise, I can not implement this API.
> 
> > 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?
> 
> Yes. My concerns are we keep adding APIs without thinking about how it
> can be implemented
> in the overall scheme of things. Just API is not enough.

We keep thinking about all scenarios (maybe in other threads).
And adding an API is a step in the right direction in my opinion.