From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH net-next 3/7] mpls: Add a sysctl to control the size of the mpls label table Date: Thu, 05 Mar 2015 08:38:25 -0600 Message-ID: <87bnk7bjby.fsf@x220.int.ebiederm.org> References: <874mq22imc.fsf_-_@x220.int.ebiederm.org> <20150303.144509.1694022322984204895.davem@davemloft.net> <87mw3tzv8u.fsf@x220.int.ebiederm.org> <20150303.153310.624302583835136622.davem@davemloft.net> <87h9u1y8y8.fsf_-_@x220.int.ebiederm.org> <87vbihtvts.fsf_-_@x220.int.ebiederm.org> <87egp5tvlz.fsf_-_@x220.int.ebiederm.org> <878ufbh93t.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain Cc: David Miller , netdev@vger.kernel.org, roopa , Stephen Hemminger , santiago@crfreenet.org, Simon Horman To: Vivek Venkatraman Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]:33772 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbbCEOmC (ORCPT ); Thu, 5 Mar 2015 09:42:02 -0500 In-Reply-To: <878ufbh93t.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Thu, 05 Mar 2015 07:22:46 -0600") Sender: netdev-owner@vger.kernel.org List-ID: ebiederm@xmission.com (Eric W. Biederman) writes: > Vivek Venkatraman writes: > >> On Tue, Mar 3, 2015 at 5:11 PM, Eric W. Biederman 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. A couple more thoughts. The rtnetlink interface and my implementation carries a type field so it is possible to mark which routing protocol uses an mpls route. The global routing table is already over 500,000 routes so the 1 million forward equivalanece classes of mpls with a single label may be exhausted in the not too distant future so a dense label space may be a necessity. In a similar vein. When I look at top of rack switches and their hardware forwarding capacity it looks like they are in the ballpark of 32K MPLS routes. All of which says to me that the MPLS label space is limited and it should be managed as a precious resource. (A good example of why I might want to rethink my mpls ingress path). So while I can see arguments for one use of labels getting one quota of labels and another use of labels getting another quota when I look at the space there are not that many labels and I don't see how or why it would make sense to manage the labels explicitly with ranges. At some point for MPLS multicast traffic and MPLS source specific addresses if we choose to support those we will need a hash table as those addresses are assigned by others, though in that case we will be limited in our egress set of labels we can use. So I think MPLS interfaces need to encourage thrifty label use, which in my mind almost certainly means not manually allocated label use. Eric