netdev - Re: [RFC PATCH] net: Add support for virtual machine device queues (VMDQ)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 28 Aug 2012 00:39:46 +0300
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	John Fastabend <john.r.fastabend@...el.com>
Cc:	netdev@...r.kernel.org, Ali Ayoub <ali@...lanox.com>
Subject: Re: [RFC PATCH] net: Add support for virtual machine device queues (VMDQ)

John Fastabend <john.r.fastabend@...el.com> wrote:
> Or Gerlitz wrote:
>> John Fastabend <john.r.fastabend@...el.com> wrote:

>>> That seems reasonable to me. Adding a 'sub' argument to the set
>>> routines should do it. Also the 'get' routines would need to be
>>> extended to report back these virtual net devices.
>>>
>>> int (*ndo_set_vf_mac)(struct net_device *dev, int vf, int sub, u8* mac);
>>> int (*ndo_set_vf_vlan)(struct net_device *dev,
>>>                         int vf, int sub, u16 vlan, u8 qos);
>>> int (*ndo_set_vf_tx_rate)(struct net_device *dev,
>>>                            int vf, int sub, int rate);
>>> int (*ndo_set_vf_spoofchk)(struct net_device *dev,
>>>                             int vf, int sub, bool setting);
>>> int (*ndo_get_vf_config)(struct net_device *dev,
>>>                           int vf, int sub,
>>>                           struct fila_vf_info *ivf)

>>> I would need to check if any of the ixgbe/igb supported hardware can
>>> support virtual device queues on virtual functions like this but I
>>> presume if your looking at this you have some hardware that can.

>> Yes, we look on HW that can. Your suggestion makes sense,  I will check here
>> if this well addresses the eswitch use case we envision or/what is missing.

> Sounds good let us know. Ben had some comments I need to address as well.

Thinking on this use case a little further, another concern/challenge
would actually be
**creating** these VMDQ interfaces in the guest that has the VF mapped into.

Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html