[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1fAEDkgAG3ttvOQ@shredder>
Date: Tue, 25 Oct 2022 13:53:04 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
roopa@...dia.com, razor@...ckwall.org, mlxsw@...dia.com
Subject: Re: [RFC PATCH net-next 00/19] bridge: mcast: Extensions for EVPN
On Tue, Oct 18, 2022 at 12:21:12PM -0700, Jakub Kicinski wrote:
> On Tue, 18 Oct 2022 15:04:01 +0300 Ido Schimmel wrote:
> > [ MDBE_ATTR_SRC_LIST ] // new
> > [ MDBE_SRC_LIST_ENTRY ]
> > [ MDBE_SRCATTR_ADDRESS ]
> > struct in_addr / struct in6_addr
> > [ ...]
>
> nit: I found that the MDBE_ATTR_SRC_LIST level of wrapping corresponds
> to how "sane" formats work, but in practice there is no need for it in
> netlink. You can put the entry nests directly in the outer. Saves one
> layer of parsing. Just thought I'd mention it, you can keep as is if
> you prefer.
I guess you mean:
[ MDBA_SET_ENTRY_ATTRS ]
[ MDBE_SRC_LIST_ENTRY ]
[ MDBE_SRCATTR_ADDRESS ]
struct in_addr / struct in6_addr
[ MDBE_SRC_LIST_ENTRY ]
[ ... ]
It is a good suggestion, but I wanted to make the request format similar
to the existing response / notification format that already has this
level of wrapping. See example in the commit message of patch #17:
https://lore.kernel.org/netdev/20221018120420.561846-18-idosch@nvidia.com/
Powered by blists - more mailing lists