netdev - RE: [net-next 07/11] if_link: Add VF multicast promiscuous control

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 May 2015 05:55:25 +0000
From:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
To:	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	Or Gerlitz <gerlitz.or@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"nhorman@...hat.com" <nhorman@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"jogreene@...hat.com" <jogreene@...hat.com>,
	"Choi, Sy Jong" <sy.jong.choi@...el.com>,
	Edward Cree <ecree@...arflare.com>,
	Rony Efraim <ronye@...lanox.com>
Subject: RE: [net-next 07/11] if_link: Add VF multicast promiscuous control

> > -----Original Message-----
> > From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> > Sent: Sunday, May 03, 2015 7:16 AM
> > To: Kirsher, Jeffrey T
> > Cc: David Miller; Hiroshi Shimamoto; Linux Netdev List;
> > nhorman@...hat.com; sassmann@...hat.com; jogreene@...hat.com;
> > Choi, Sy Jong; Edward Cree; Skidmore, Donald C; Rony Efraim
> > Subject: Re: [net-next 07/11] if_link: Add VF multicast promiscuous control
> >
> > On Sat, May 2, 2015 at 1:42 PM, Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> > wrote:
> > > From: Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
> > >
> > > Add netlink directives and ndo entry to allow VF multicast promiscuous
> > mode.
> > >
> > > This controls the permission to enter VF multicast promiscuous mode.
> > > The administrator will dedicatedly allow multicast promiscuous per VF.
> > >
> > > When the VF is under multicast promiscuous mode, all multicast packets
> > > are sent to the VF.
> > >
> > > Don't allow VF multicast promiscuous if the VM isn't fully trusted.
> >
> > Guys,
> >
> > I don't think the discussion we held in the past [1] on the matter actually
> > converged. Few open points that came up while debating it internally with
> > Rony:
> >
> > 1. maybe what we we actually want here an API that states a VF to be
> > privileged/trusted and then we can over load the feature set of being such?
> 
> I suggested this originally, but there was push back as it was thought too generic as the definition of what being a "trusted"
> vendor would differ from driver to driver.  Personally I still like the idea of having one mode saying that we "trust"
> a given VF.  Then that VF can request whatever it support it wants from the PF regardless of possible negative impact
> on other VF's.  What is possible to support would then be left to the interface between the VF and PF.  This of course
> would be dependent on what the given HW could support and would mean this mode would mean different things for different
> adapters and I do see why some might see this as a concern.

The point is granularity, right?
Allow everything or allow subset of features.

> 
> >
> > 2. the suggested API only allows either unlimited number of mulicast groups
> > per VF or limited number, both numbers are vendor dependent, right?
> > maybe what we need for this specific matter is specifying how many
> > multicast groups are allowed for a VF?
> 
> I believe the idea behind this interface was that it would allow VF's to request unlimited multicast group as opposed
> to the current behavior of each adapter offering some limited number.  This limit is of course defined by a given adapters
> HW/SW limitations.  Up until now you could keep asking for new multicast until the PF replied with an error.  So we never
> really exported this information before.  This new mode just allows us to never reach the point that the PF would deny
> a VF request to join a MC group.  Seems to me that an additional interface to provide the max number of supported multicast
> groups would be new functionality that could be independent of this patch and in fact could exist even without this patch.
> Or am I missing what you're asking for here. :)

I think that the current limitation of multicast on ixgbevf comes from the
implementation of mailbox API between VF and PF which has 32 words.

By the way, our requirement is to make VF promiscuous mode for SDN/NFV usage.
And there is a feature to enable in HW, we'd like to use it.
I know there is a possibility of performance degradation.

thanks,
Hiroshi