From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Lixue Liang <lianglixuehao@126.com>,
anthony.l.nguyen@intel.com, linux-kernel@vger.kernel.org,
jesse.brandeburg@intel.com, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org,
lianglixue@greatwall.com.cn,
Alexander H Duyck <alexander.duyck@gmail.com>
Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one
Date: Sun, 18 Dec 2022 10:41:32 +0200 [thread overview]
Message-ID: <Y57SPPmui6cwD5Ma@unreal> (raw)
In-Reply-To: <20221214125016.5a23c32a@kernel.org>
On Wed, Dec 14, 2022 at 12:50:16PM -0800, Jakub Kicinski wrote:
> On Wed, 14 Dec 2022 20:53:30 +0200 Leon Romanovsky wrote:
> > On Wed, Dec 14, 2022 at 08:51:06AM -0800, Jakub Kicinski wrote:
> > > On Wed, 14 Dec 2022 09:22:13 +0200 Leon Romanovsky wrote:
> > > > NAK to any module driver parameter. If it is applicable to all drivers,
> > > > please find a way to configure it to more user-friendly. If it is not,
> > > > try to do the same as other drivers do.
> > >
> > > I think this one may be fine. Configuration which has to be set before
> > > device probing can't really be per-device.
> >
> > This configuration can be different between multiple devices
> > which use same igb module. Module parameters doesn't allow such
> > separation.
>
> Configuration of the device, sure, but this module param is more of
> a system policy.
And system policy should be controlled by userspace and applicable to as
much as possible NICs, without custom module parameters.
I would imagine global (at the beginning, till someone comes forward and
requests this parameter be per-device) to whole stack parameter with policies:
* Be strict - fail if mac is not valid
* Fallback to random
* Random only ???
Thanks
next prev parent reply other threads:[~2022-12-18 8:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 7:47 [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one Lixue Liang
2022-12-13 19:22 ` Tony Nguyen
2022-12-14 7:22 ` Leon Romanovsky
2022-12-14 10:02 ` 梁礼学
2022-12-14 16:51 ` Jakub Kicinski
2022-12-14 18:53 ` Leon Romanovsky
2022-12-14 20:50 ` Jakub Kicinski
2022-12-14 21:43 ` Heiner Kallweit
2022-12-14 23:17 ` Alexander Duyck
2022-12-15 3:24 ` 梁礼学
2022-12-15 15:49 ` Alexander H Duyck
2022-12-19 18:25 ` Jacob Keller
2022-12-18 8:41 ` Leon Romanovsky [this message]
2022-12-19 15:30 ` Alexander Duyck
2022-12-28 9:15 ` Leon Romanovsky
2022-12-30 16:17 ` Andrew Lunn
-- strict thread matches above, loose matches on Subject: below --
2022-12-14 1:12 Lixue Liang
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=Y57SPPmui6cwD5Ma@unreal \
--to=leon@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=lianglixue@greatwall.com.cn \
--cc=lianglixuehao@126.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.