mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: "Skidmore\, Donald C" <donald.c.skidmore@intel.com>
Cc: David Laight <David.Laight@ACULAB.COM>,
	Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>,
	"e1000-devel\@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>, "Choi\,
	Sy Jong" <sy.jong.choi@intel.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Hayato Momma <h-momma@ce.jp.nec.com>
Subject: Re: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
Date: Thu, 22 Jan 2015 20:31:52 +0100	[thread overview]
Message-ID: <87bnlqpq6v.fsf@nemi.mork.no> (raw)
In-Reply-To: <F6FB0E698C9B3143BDF729DF222866469129BFFD@ORSMSX110.amr.corp.intel.com> (Donald C. Skidmore's message of "Thu, 22 Jan 2015 19:00:51 +0000")

"Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:

> My hang up is more related to: without the nob to enable it (off by
> default) we are letting one VF dictate policy for all the other VFs
> and the PF.  If one VF needs to be in promiscuous multicast so is
> everyone else.  Their stacks now needs to deal with all the extra
> multicast packets.  As you point out this might not be a direct
> concern for isolation in that the VM could have 'chosen' to join any
> Multicast group and seen this traffic.  My concern over isolation is
> one VF has chosen that all the other VM now have to see this multicast
> traffic.

Apologies if this question is stupid, but I just have to ask about stuff
I don't understand...

Looking at the proposed implementation, the promiscous multicast flag
seems to be a per-VF flag:

+int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool setting)
+{
+	struct ixgbe_adapter *adapter = netdev_priv(netdev);
+	struct ixgbe_hw *hw = &adapter->hw;
+	u32 vmolr;
+
+	if (vf >= adapter->num_vfs)
+		return -EINVAL;
+
+	adapter->vfinfo[vf].mc_promisc_enabled = setting;
+
+	vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+	if (setting) {
+		e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
+		vmolr |= IXGBE_VMOLR_MPE;
+	} else {
+		e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
+		vmolr &= ~IXGBE_VMOLR_MPE;
+	}
+
+	IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+	return 0;
+}
+

I haven't read the data sheet, but I took a quick look at the excellent
high level driver docs:
http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-driver-companion-guide.pdf

It mentions "Multicast Promiscuous Enable" in its "Thoughts for
Customization" section:

 7.1 Multicast Promiscuous Enable

 The controller has provisions to allow each VF to be put into Multicast
 Promiscuous mode.  The Intel reference driver does not configure this
 option .

 The capability can be enabled/disabled by manipulating the MPE field
 (bit 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)

and showing a section from the data sheet describing the
"PF VM L2 Control Register - PFVML2FLT[n]  (0x0F000 + 4 * n, n=0...63; RW)"

To me it looks like enabling Promiscuos Multicast for a VF won't affect
any other VF at all.  Is this really not the case?



Bjørn

  reply	other threads:[~2015-01-22 19:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20 10:50 Hiroshi Shimamoto
2015-01-20 11:42 ` Bjørn Mork
2015-01-20 23:40   ` Hiroshi Shimamoto
2015-01-21  0:26     ` [E1000-devel] " Skidmore, Donald C
2015-01-21  1:07       ` Hiroshi Shimamoto
2015-01-21  1:30         ` Skidmore, Donald C
2015-01-21 11:38           ` Hiroshi Shimamoto
2015-01-21 11:56             ` David Laight
2015-01-21 12:18               ` Hiroshi Shimamoto
2015-01-21 20:27                 ` Skidmore, Donald C
2015-01-22  9:50                   ` David Laight
2015-01-22 10:52                     ` Jeff Kirsher
2015-01-22 19:00                     ` Skidmore, Donald C
2015-01-22 19:31                       ` Bjørn Mork [this message]
2015-01-22 21:34                         ` Skidmore, Donald C
2015-01-23  0:32                           ` Hiroshi Shimamoto
2015-01-23  1:21                             ` Skidmore, Donald C
2015-01-23  7:18                             ` Alexander Duyck
2015-01-23 18:24                               ` Skidmore, Donald C
2015-01-27 12:53                                 ` Hiroshi Shimamoto
2015-01-27 17:34                                   ` Alexander Duyck
2015-01-21  9:26     ` Bjørn Mork
2015-01-20 11:53 ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bnlqpq6v.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=David.Laight@ACULAB.COM \
    --cc=donald.c.skidmore@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=h-momma@ce.jp.nec.com \
    --cc=h-shimamoto@ct.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sy.jong.choi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®