From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, <netdev@vger.kernel.org>,
Ido Schimmel <idosch@nvidia.com>, Amit Cohen <amcohen@nvidia.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
"Andy Roulin" <aroulin@nvidia.com>, <mlxsw@nvidia.com>
Subject: Re: [PATCH net-next v2 0/8] net: Shift responsibility for FDB notifications to drivers
Date: Mon, 4 Nov 2024 19:06:10 -0800 [thread overview]
Message-ID: <20241104190610.391b784a@kernel.org> (raw)
In-Reply-To: <87ldxzky77.fsf@nvidia.com>
On Mon, 4 Nov 2024 12:43:11 +0100 Petr Machata wrote:
> > On Thu, 24 Oct 2024 18:57:35 +0200 Petr Machata wrote:
> >> Besides this approach, we considered just passing a boolean back from the
> >> driver, which would indicate whether the notification was done. But the
> >> approach presented here seems cleaner.
> >
> > Oops, I missed the v2, same question:
> >
> > What about adding a bit to the ops struct to indicate that
> > the driver will generate the notification? Seems smaller in
> > terms of LoC and shifts the responsibility of doing extra
> > work towards more complex users.
> >
> > https://lore.kernel.org/all/20241029121619.1a710601@kernel.org/
>
> Sorry for only responding now, I was out of office last week.
>
> The reason I went with outright responsibility shift is that the
> alternatives are more complex.
>
> For the flag in particular, first there's no place to set the flag
> currently, we'd need a field in struct net_device_ops. But mainly, then
> you have a code that needs to corrently handle both states of the flag,
> and new-style drivers need to remember to set the flag, which is done in
> a different place from the fdb_add/del themselves. It might be fewer
> LOCs, but it's a harder to understand system.
>
> Responsibility shift is easy. "Thou shalt notify." Done, easy to
> understand, easy to document. When cut'n'pasting, you won't miss it.
Makes sense for real proto drivers, but we also need to touch 4
Ethernet drivers. While we can trust proto drivers to do the right
thing, HW driver devs on average are average. And I can't think of
another case where driver would send netlink notifications directly.
> Let me know what you think.
Mild preference towards keeping the expectations from HW drivers as low
as possible. But I don't feel strongly. Let me revive the series in PW
so it is top of the list for Paolo tomorrow.. :)
next prev parent reply other threads:[~2024-11-05 3:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 16:57 [PATCH net-next v2 0/8] net: Shift responsibility for FDB notifications to drivers Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 1/8] net: rtnetlink: Publish rtnl_fdb_notify() Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 2/8] ndo_fdb_add: Shift responsibility for notifying to drivers Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 3/8] ndo_fdb_del: " Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 4/8] selftests: net: lib: Move logging from forwarding/lib.sh here Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 5/8] selftests: net: lib: Move tests_run " Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 6/8] selftests: net: lib: Move checks " Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 7/8] selftests: net: lib: Add kill_process Petr Machata
2024-10-24 16:57 ` [PATCH net-next v2 8/8] selftests: net: fdb_notify: Add a test for FDB notifications Petr Machata
2024-10-29 19:18 ` [PATCH net-next v2 0/8] net: Shift responsibility for FDB notifications to drivers Jakub Kicinski
2024-11-04 11:43 ` Petr Machata
2024-11-05 3:06 ` Jakub Kicinski [this message]
2024-11-05 9:11 ` Paolo Abeni
2024-11-05 9:45 ` Petr Machata
2024-11-05 10:12 ` Paolo Abeni
2024-11-05 11:38 ` Petr Machata
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=20241104190610.391b784a@kernel.org \
--to=kuba@kernel.org \
--cc=amcohen@nvidia.com \
--cc=aroulin@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).