RE: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

["Skidmore, Donald C" <donald.c.skidmore@intel.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3720 bytes --]



-----Original Message-----
From: Edward Cree [mailto:ecree@solarflare.com] 
Sent: Friday, February 20, 2015 5:52 AM
To: Hiroshi Shimamoto
Cc: Skidmore, Donald C; vyasevic@redhat.com; Kirsher, Jeffrey T; Alexander Duyck; Bjørn Mork; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy Jong; linux-kernel@vger.kernel.org; David Laight; Hayato Momma
Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

On 20/02/15 01:00, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
> Add netlink directives and ndo entry to allow VF multicast promiscuous mode.
>
> The administrator wants to allow dedicatedly multicast promiscuous per VF.
If I'm properly understanding, this seems to be an ixgbe-specific option to work around an ixgbe limitation; is it really appropriate to implement as a generic net_device_op?
What would this ndo mean to a driver which can support thousands of multicast groups without MC promisc?  Is it expected to limit the number of MC groups when this is set to disallow?  Or just fulfil the letter of the option but not its spirit?  The option doesn't seem to have well-defined semantics outside of ixgbe.
I would suggest that the right place for this sort of driver-specific device control is in sysfs.

I'm also a little perplexed as to why anyone would need to disallow this; what security, or even administrative convenience, is gained by allowing a VF to join 30 multicast groups but not multicast promiscuous mode?  Especially as, afaik, there are no restrictions on which multicast groups are joined, so the VF can receive any particular multicast traffic it cares about.
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly 
prohibited.


If a vender specific interface is objectionable maybe a simpler and more generic interface would be for the PF to be able to set a given VF into "trusted" mode.  Then when the VF requested to enter multicast promiscuous mode via the mailbox message the PF would just allow it?  This could then be used to address other issues where we don't want to allow a VF to do something due to isolation or performance concerns.  I admit exactly what 'trusted' meant would vary from vender to vender, but it would be a way for the driver to know it could allow configurations such as this.  Just an idea, since we seem to be getting more requests for things such as this.

As to why someone may want to block a VF from entering multicast promiscuous it has more to do with performance that security.  The issue is this could have a very noticeably effect  on the overall system.  If any other VFs (or the PF) are receiving MC packets these will have to be replicated which will be a performance hit.  When we use the MC hash this is limited vs. when anyone is in MC promiscuous every MC packet used by another pool would be replicated. .  If too many VF's were in this mode you run the risk for flooding the PCIe interface.  I could imagine in some environments (i.e. public clouds) where you don't trust what is running in your VM you might what to block this from happening.

- Don Skidmore <donald.c.skidmore@intel.com>

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥