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
next prev parent 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®