On Fri, Nov 15, 2019 at 12:27 PM Thomas Monjalon wrote:
>
> 07/11/2019 06:02, Jerin Jacob:
> > On Thu, Nov 7, 2019 at 4:03 AM Alex Williamson
> > wrote:
> > > Ideas have been suggested
> > > upstream for for quarantining VFs generated from user owned PFs such
> > > that we require an opt-in to ma
07/11/2019 06:02, Jerin Jacob:
> On Thu, Nov 7, 2019 at 4:03 AM Alex Williamson
> wrote:
> > Ideas have been suggested
> > upstream for for quarantining VFs generated from user owned PFs such
> > that we require an opt-in to make use of them in this way. Nobody
> > seems to be pursuing such ideas
On Thu, Nov 7, 2019 at 4:03 AM Alex Williamson
wrote:
>
> On Thu, 31 Oct 2019 18:03:53 +0100
> Thomas Monjalon wrote:
>
> > We don't get enough attention on this topic.
> > Let me rephrase the issue and the proposals with more people Cc'ed.
> >
> > We are talking about SR-IOV VFs in VMs
> > with
On Thu, 31 Oct 2019 18:03:53 +0100
Thomas Monjalon wrote:
> We don't get enough attention on this topic.
> Let me rephrase the issue and the proposals with more people Cc'ed.
>
> We are talking about SR-IOV VFs in VMs
> with a PF managed on the host by DPDK.
> The PF driver is either a (1) bifur
On Mon, 2019-11-04 at 11:16 +, Bruce Richardson wrote:
> On Fri, Nov 01, 2019 at 11:54:45AM +, Luca Boccassi wrote:
> > For distros, out-of-tree kernel modules are painful. From my POV,
> > it
> > would be preferable to try and find a solution upstream, even if it
> > is
> > going to be dif
On Fri, Nov 01, 2019 at 11:54:45AM +, Luca Boccassi wrote:
> For distros, out-of-tree kernel modules are painful. From my POV, it
> would be preferable to try and find a solution upstream, even if it is
> going to be difficult and require a lot of negotiation and work.
>
I don't think anyone
On Fri, Nov 1, 2019 at 5:24 PM Luca Boccassi wrote:
>
> For distros, out-of-tree kernel modules are painful. From my POV, it
I agree.
> would be preferable to try and find a solution upstream, even if it is
> going to be difficult and require a lot of negotiation and work.
I understand from RH,
For distros, out-of-tree kernel modules are painful. From my POV, it
would be preferable to try and find a solution upstream, even if it is
going to be difficult and require a lot of negotiation and work.
On Thu, 2019-10-31 at 18:03 +0100, Thomas Monjalon wrote:
> We don't get enough attention on
We don't get enough attention on this topic.
Let me rephrase the issue and the proposals with more people Cc'ed.
We are talking about SR-IOV VFs in VMs
with a PF managed on the host by DPDK.
The PF driver is either a (1) bifurcated (Mellanox case),
or (2) bound to UIO with igb_uio, or (3) bound to
> > >
> >
> > There is security issue in attaching DPDK PF driver and netdev bind to VF.
> > So this scheme is not upsteamble to Linux kernel. Since rte_flow had VF
> > action. We need this scheme to support VF action with VFIO. So, Out of tree
> > is the only way as it is DPDK specific feature. Al
On Wed, Oct 16, 2019 at 5:07 PM Jerin Jacob wrote:
>
> > >
> > >
> > > no-iommu case is different where we cannot screw Linux netdev driver, you
> > > can create a damage to your self that's an acceptable compromise.
> > >
> > > In this case, when DPDK PF bound application dies then it will impac
> >
> >
> > no-iommu case is different where we cannot screw Linux netdev driver, you
> > can create a damage to your self that's an acceptable compromise.
> >
> > In this case, when DPDK PF bound application dies then it will impact
> > netdev VF driver as gets stalled and there is a security is
On Thu, Oct 10, 2019 at 11:32 AM Jerin Jacob wrote:
>
>
>
> On Thu, 10 Oct, 2019, 4:58 AM Stephen Hemminger,
> wrote:
>>
>> On Tue, 8 Oct 2019 20:58:27 +0530
>> Jerin Jacob wrote:
>>
>> > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger,
>> >
>> > wrote:
>> >
>> > > On Fri, 6 Sep 2019 14:42:30
On Thu, 10 Oct, 2019, 4:58 AM Stephen Hemminger,
wrote:
> On Tue, 8 Oct 2019 20:58:27 +0530
> Jerin Jacob wrote:
>
> > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger, <
> step...@networkplumber.org>
> > wrote:
> >
> > > On Fri, 6 Sep 2019 14:42:30 +0530
> > > wrote:
> > >
> > > > From: Vamsi At
On Tue, 8 Oct 2019 20:58:27 +0530
Jerin Jacob wrote:
> On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger,
> wrote:
>
> > On Fri, 6 Sep 2019 14:42:30 +0530
> > wrote:
> >
> > > From: Vamsi Attunuru
> > >
> > > The DPDK use case such as VF representer or OVS offload etc
> > > would call for PF a
On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger,
wrote:
> On Fri, 6 Sep 2019 14:42:30 +0530
> wrote:
>
> > From: Vamsi Attunuru
> >
> > The DPDK use case such as VF representer or OVS offload etc
> > would call for PF and VF PCIe devices to bind vfio-pci
> > module to enable IOMMU protection.
>
On Fri, 6 Sep 2019 14:42:30 +0530
wrote:
> From: Vamsi Attunuru
>
> The DPDK use case such as VF representer or OVS offload etc
> would call for PF and VF PCIe devices to bind vfio-pci
> module to enable IOMMU protection.
>
> In addition to vSwitch use case, unlike, other PCI class of
> device
> -Original Message-
> From: Jerin Jacob Kollanukkaran
> Sent: Friday, September 6, 2019 6:58 PM
> To: Thomas Monjalon ; Vamsi Krishna Attunuru
>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel
> module
>
6:58 PM
To: Thomas Monjalon ; Vamsi Krishna Attunuru
Cc: dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel
module
-Original Message-
From: Thomas Monjalon
Sent: Friday, September 6, 2019 3:15 PM
To: Vamsi Krishna Attunuru
Cc: dev@dpdk.org
Attunuru
Cc: dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel
module
> -Original Message-
> From: Thomas Monjalon
> Sent: Friday, September 6, 2019 3:15 PM
> To: Vamsi Krishna Attunuru
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran
> -Original Message-
> From: Thomas Monjalon
> Sent: Friday, September 6, 2019 3:15 PM
> To: Vamsi Krishna Attunuru
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran
> Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel
> module
>
&g
06/09/2019 11:12, vattun...@marvell.com:
> From: Vamsi Attunuru
>
> The DPDK use case such as VF representer or OVS offload etc
> would call for PF and VF PCIe devices to bind vfio-pci
> module to enable IOMMU protection.
>
> In addition to vSwitch use case, unlike, other PCI class of
> devices,
From: Vamsi Attunuru
The DPDK use case such as VF representer or OVS offload etc
would call for PF and VF PCIe devices to bind vfio-pci
module to enable IOMMU protection.
In addition to vSwitch use case, unlike, other PCI class of
devices, Network class of PCIe devices would have additional
resp
23 matches
Mail list logo
