netdev - Re: [PATCH net-next 3/7] mpls: Add a sysctl to control the size of the mpls label table

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: <878ufbh93t.fsf@x220.int.ebiederm.org>
Date:	Thu, 05 Mar 2015 07:22:46 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Venkatraman <vivek@...ulusnetworks.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	roopa <roopa@...ulusnetworks.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	santiago@...reenet.org, Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH net-next 3/7] mpls: Add a sysctl to control the size of the mpls label table

Vivek Venkatraman <vivek@...ulusnetworks.com> writes:

> On Tue, Mar 3, 2015 at 5:11 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> This sysctl gives two benefits.  By defaulting the table size to 0
>> mpls even when compiled in and enabled defaults to not forwarding
>> any packets.  This prevents unpleasant surprises for users.
>>
>> The other benefit is that as mpls labels are allocated locally a dense
>> table a small dense label table may be used which saves memory and
>> is extremely simple and efficient to implement.
>>
>
> The label space is often partitioned into multiple sets in MPLS and
> used for different purposes - for example, LSP labels, VPN labels,
> Segment labels. This in turn means that the table may no longer be
> dense. A sysctl allowing min and max label that spans the sets of
> labels may be useful. Or should the ILM be made a hash table?

Good question.

These kinds of labels are a local label management problem.

Given how nice it is to have a reasonably dense label space I am not
keen to abandon the notion of having a dense label space, as it makes
the code simple and fast for forwarding mpls packets.

That said my code is a starting point.  If you have a real world use
case and you can show a better way to deal with it.  Go for it.
Now is definitely time to evolve the API.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html