Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

quoted

-----Original Message-----
From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
Sent: Tuesday, January 20, 2015 5:07 PM
To: Skidmore, Donald C; Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy
Jong; linux-kernel@vger.kernel.org; Hayato Momma
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control

quoted

Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
promiscuous mode control

quoted

-----Original Message-----
From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
Sent: Tuesday, January 20, 2015 3:40 PM
To: Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi,
Sy Jong; linux-kernel@vger.kernel.org; Hayato Momma
Subject: Re: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
promiscuous mode control

quoted

Subject: Re: [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control

Hiroshi Shimamoto [off-list ref] writes:

quoted

From: Hiroshi Shimamoto <redacted>

Add netlink directives and ndo entry to control VF multicast
promiscuous

mode.

quoted

quoted

Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC
addresses per VF. It means that we cannot assign over 30 IPv6
addresses to a single VF interface on VM. We want thousands IPv6

addresses in VM.

quoted

quoted

There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.

This patch prepares to control that VF multicast promiscuous

functionality.

quoted

Adding a new hook for this seems over-complicated to me.  And it
still doesn't solve the real problems that
 a) the user has to know about this limit, and
 b) manually configure the feature

Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging
before we figure this one out...

Why can't the ixgbevf driver just automatically signal the ixgbe
driver to enable multicast promiscuous mode whenever the list
grows past the limit?

I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269

The previous patch introduces API between ixgbe and ixgbevf driver
to enable multicast promiscuous mode, and ixgbevf enables it
automatically if the number of addresses is over than 30.

I believe the issue is with allowing a VF to automatically enter
Promiscuous Multicast without the PF's ok is concern

So you mean that we should take care about enabling VF multicast
promiscuous mode in host side, right? The host allows multicast promiscuous
and VF requests it too, then enables VF multicast promiscuous mode.
So, what is preferred way to do in host do you think?

I think we are saying the same thing.  I believe it would be fine if the VF requests this to happen (threw a mailbox message
like you set up) and the PF will do it if the systems policy has been set up that way (as you did with the control mode).

This way the behavior (related to multicast) is the same as it has been, unless the system has been setup specifically
to allow VF multicast promiscuous mode.

Now I understand what you're saying.
Will make patches that make knob in host/PF and ixgbe/ixgbevf interface.
I think I should try to find whether there is a way to make the know without ndo.

I know it's been mentioned that this is onerous on those who want this behavior to be automatic, but I don't see how else
it could be done and take account for people that are concerned about allowing a (possibly untrusted) VM promoting itself
in to multicast promiscuous mode.

I didn't mind its onerousness so much.
My concern is what is the real issue that VF multicast promiscuous mode can cause.
I think there is the 4k entries to filter multicast address, and the current ixgbe/ixgbevf
can turn all bits on from VM. That is almost same as enabling multicast promiscuous mode.
I mean that we can receive all multicast addresses by an onerous operation in untrusted VM.
I think we should clarify what is real security issue in this context.

thanks,
Hiroshi

quoted

quoted

over VM isolation.   Of course that isolation, when it comes to multicast, is

rather limited anyway given that our multicast

quoted

filter uses only 12-bit of the address for a match.  Still this (or
doing it by default) would only open that up considerably more (all
multicasts).  I assume for your application you're not concerned, but are

there other use cases that would worry about such things?

Sorry I couldn't catch the point.

What is the issue? I think there is no difference for the users who don't want
many multicast addresses in guest. In the current implementation,
overflowed multicast addresses silently discarded in ixgbevf. I believe there
is no user who want to use over 30 multicast addresses now. If VF multicast
promiscuous mode is enabled in certain VF, the behavior of other VFs is not
changed.

thanks,
Hiroshi

quoted

Thanks,
-Don Skidmore [off-list ref]

quoted

I got some comment and I would like to clarify the point, but there
was no answer.
That's the reason I submitted this patch.

Do you think a patch for the ixgbe/ixgbevf driver is preferred?


thanks,
Hiroshi

quoted

I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:

static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
					  struct net_device *netdev)
{
	struct netdev_hw_addr *ha;
	u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
	u16 *vector_list = (u16 *)&msgbuf[1];
	u32 cnt, i;

	/* Each entry in the list uses 1 16 bit word.  We have 30
	 * 16 bit words available in our HW msg buffer (minus 1 for the
	 * msg type).  That's 30 hash values if we pack 'em right.  If
	 * there are more than 30 MC addresses to add then punt the
	 * extras for now and then add code to handle more than 30 later.
	 * It would be unusual for a server to request that many multi-cast
	 * addresses except for in large enterprise network environments.
	 */



The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case...  It's obvious that
30 multicast addresses is ridiculously low for lots of normal use cases.


Bjørn

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired