From: "Bjørn Mork" <bjorn@mork.no>
To: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Cc: Alexander Duyck <alexander.duyck@gmail.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>,
Hayato Momma <h-momma@ce.jp.nec.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
Date: Tue, 20 Jan 2015 12:42:57 +0100 [thread overview]
Message-ID: <874mrlu18e.fsf@nemi.mork.no> (raw)
In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD05E0734E@BPXM14GP.gisp.nec.co.jp> (Hiroshi Shimamoto's message of "Tue, 20 Jan 2015 10:50:23 +0000")
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> writes:
> From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
> Add netlink directives and ndo entry to control VF multicast promiscuous mode.
>
> 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.
>
> 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.
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'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
next prev parent reply other threads:[~2015-01-20 11:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 10:50 [PATCH 1/2] if_link: Add VF multicast promiscuous mode control Hiroshi Shimamoto
2015-01-20 11:42 ` Bjørn Mork [this message]
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
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=874mrlu18e.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=alexander.duyck@gmail.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