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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87iog0scw8.fsf@nemi.mork.no>
Date:	Wed, 21 Jan 2015 10:26:15 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	"e1000-devel\@lists.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
	"Choi\, Sy Jong" <sy.jong.choi@...el.com>,
	Hayato Momma <h-momma@...jp.nec.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

Hiroshi Shimamoto <h-shimamoto@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/