netdev - Re: [RFC PATCH 03/13] nexthop: Add netlink defines and enumerators for resilient NH groups

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <875z2tbloo.fsf@nvidia.com>
Date:   Mon, 15 Feb 2021 12:43:51 +0100
From:   Petr Machata <petrm@...dia.com>
To:     Ido Schimmel <idosch@...sch.org>
CC:     David Ahern <dsahern@...il.com>, Petr Machata <petrm@...dia.com>,
        <netdev@...r.kernel.org>, David Ahern <dsahern@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH 03/13] nexthop: Add netlink defines and enumerators
 for resilient NH groups


Ido Schimmel <idosch@...sch.org> writes:

> On Sat, Feb 13, 2021 at 12:16:45PM -0700, David Ahern wrote:
>> On 2/8/21 1:42 PM, Petr Machata wrote:
>> > @@ -52,8 +53,50 @@ enum {
>> >  	NHA_FDB,	/* flag; nexthop belongs to a bridge fdb */
>> >  	/* if NHA_FDB is added, OIF, BLACKHOLE, ENCAP cannot be set */
>> >  
>> > +	/* nested; resilient nexthop group attributes */
>> > +	NHA_RES_GROUP,
>> > +	/* nested; nexthop bucket attributes */
>> > +	NHA_RES_BUCKET,
>> > +
>> >  	__NHA_MAX,
>> >  };
>> >  
>> >  #define NHA_MAX	(__NHA_MAX - 1)
>> > +
>> > +enum {
>> > +	NHA_RES_GROUP_UNSPEC,
>> > +	/* Pad attribute for 64-bit alignment. */
>> > +	NHA_RES_GROUP_PAD = NHA_RES_GROUP_UNSPEC,
>> > +
>> > +	/* u32; number of nexthop buckets in a resilient nexthop group */
>> > +	NHA_RES_GROUP_BUCKETS,
>> 
>> u32 is overkill; arguably u16 (64k) should be more than enough buckets
>> for any real use case.
>
> We wanted to make it future-proof, but I think we can live with 64k. At
> least in Spectrum the maximum is 4k. I don't know about other devices,
> but I guess it is not more than 64k.

OK, no problem. I was thinking of keeping the API as u32, and tracking
as u16 internally, but let's not add baggage at this stage already. Push
comes to shove there can be another u32 attribute mutexed with this one.