Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com> writes: >> 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 got some comment and I would like to clarify the point, but there was no > answer. > That's the reason I submitted this patch.
Thanks. Yes, now I understand why you want to have a policy knob. I still think the policy could select between "automatic"/"disallowed" instead of "enabled"/"disabled", but that's a minor detail. Likewise is the actual implemention of "automatic". I think you could do that within the current VF-PF protocol by overloading the MC address "count". But a more generic question for netdev is: Does this VF policy API really scale? How many different VF policy tunables can you imaging add up over a few years and drivers. Currently each policy flag require its own ndo hook. I probably don't have much to say here, but IMHO this scheme had already failed when .ndo_set_vf_spoofchk was added.. 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
