From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id E42158EA0 for ; Fri, 30 Oct 2015 22:55:21 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 30 Oct 2015 14:55:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,220,1444719600"; d="scan'208";a="591276620" Received: from sfitzsim-mobl1.ger.corp.intel.com ([10.252.27.213]) by FMSMGA003.fm.intel.com with SMTP; 30 Oct 2015 14:55:18 -0700 Received: by (sSMTP sendmail emulation); Fri, 30 Oct 2015 21:55:16 +0025 Date: Fri, 30 Oct 2015 21:55:16 +0000 From: Bruce Richardson To: Vladimir Medvedkin Message-ID: <20151030215516.GA12128@bricha3-MOBL3> References: <20151030120018.GA4904@bricha3-MOBL3> <20151030175927.GA21104@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] lpm patches X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 21:55:22 -0000 On Fri, Oct 30, 2015 at 10:34:54PM +0300, Vladimir Medvedkin wrote: > Hi all, > > 2015-10-30 20:59 GMT+03:00 Matthew Hall : > > > On Fri, Oct 30, 2015 at 12:00:18PM +0000, Bruce Richardson wrote: > > > Matthew's patches were attachments, I don't think they came through in > > patchwork > > > correctly :-(, but that is the relevant link there anyway.] > > > > Let me know if there is something I can do better there. I was having a > > difficult time figuring out how to preserve the thread ID in the middle of > > the > > thread and not cause a new thread. The git email workflows are very > > confusing > > and I figured it was better to send something as soon as I could. > > > > > * Some patches increase the next-hop to 16 bits, others to 24-bits. In > > both cases > > > a single entry still only occupies 32-bits, so can be read/written to > > > atomically > > > > I went with 24 because it was the biggest amount I could get that still had > > this property. > > > > > * Only Michal's set appears to take into account ABI versioning, which is > > > a difficult problem for this lib, with inlined functions. > > > > Agreed. His patches are the most professional from this perspective. This > > is > > why I was trying to contribute to you and to him so we get the most > > professional result for the customers. > > > > > * Matthew's patchset moves the lookup functions to be non-inlined, which > > will > > > make future updates easier from ABI compatibility - at the cost of > > lookup > > > performance. > > > > This point is optional for me. I did it, because without it, it was totally > > impossible for me to work on the code in a debugger as I am a security > > engineering guy not a crazy embedded C coder or kernel hacker. > > > > > * Vladimir's patchset merges in the tbl24 and tbl8 entries into a single > > data > > > type. > > > > I really liked this feature of Vladimir's patches, it makes it easier to > > maintain and less confusing. I had a lot of headaches keeping all those > > structs straight with the separate types, but I didn't know we had the > > chance > > for a great big MEGA-REFACTOR. I love this community! > > > > > * That patchset also introduces an extra optional 32-bit field "as_num", > > allowing > > > 64-bit lpm table entries - obviously at a cost of increased > > memory/cache > > > footprint. > > > > Is there a way we could test it? Vladimir, did you test the performance? If > > so, what happened? > > > Performance regression depends on the traffic pattern and cache size. > > > > > > * Stephen's patchset includes a range of other fixes e.g. for more > > efficient > > > management of the rules array, and dynamic allocation of the TBL8s. > > > * Matthew's patchset also includes change to LPM for IPv6, which I'm > > considering > > > out-of-scope for now, so as to focus on LPM v4 only. > > > > Any chance that is inconsistent betwen LPM4 and LPM6 really hoses me, > > because > > I am writing green-field code which treats both protocols as first-class > > citizens and I'd really not like to have totally inconsistent and inferior > > support in one versus the other. > > > > > * Increase next hops to be the full 24 bits, so as to allow maximum > > flexibility > > > and not waste the extra 8 bits of space in the 32-bit entries. > > > > +1 > > > +1. Split of next hop and forwarding class I can do in app logic. > > > > > > * Move the lookup functions which work on multiple packets to be > > non-inlined > > > > Open to opinions on the performance of this. I am not an expert on this > > area. > > > > > * Merge in the tbl24 and tbl8 structures to make the code that little > > bit shorter > > > > +1 > > > > > * Look to pull in as many of Stephen's other improvements as possible - > > though > > > this may be in a separate patchset to the other changes. > > > > +1. Perhaps if we get a pre-release on a branch with everything else, we > > could > > see if Stephen is willing to rebase his non-duplicate changes. > > > > > * I'm uncertain as to the extra 32-bit as_num field. Adding it as an > > extra > > > #define is trivial, but adds to the compile-time config. Having it as > > a run-time > > > option is possible, but likely will make the code a lot more > > complicated, as > > > we no longer have arrays of a fixed size. > > > > > > Naturally, with whatever solution is come up with, ABI compatibility > > must be > > > taken into account and functions versionned appropriately! > > > > Normally I am not a big define guy. But it seems like a define is good > > here. > > Somebody is going to need to know beforehand if they are making a Core > > Router > > where they want this, or a Security Inspection system like mine, etc. > > > For example in case of core router as_num feature can be necessary for > netflow. It can be necessary in case of security device such as my ddos > mitigation system. > > > > > So it seems easier than doing a bunch of crazy size-juggling in the code. > > > > > do we want to have some of these changes in 2.2? > > > > Personally I am OK to wait as I have it working in my copy. I am just > > trying > > to be a good citizen of the community and contribute back when I see some > > core > > engineers going after the same code. > > > > In particular, for me, having LPM4 only with no LPM6 is not worth much so > > I'd > > be happy to wait for a single upgrade to both of them. > > > > > Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this? > > > [do I accurately sum up the situation?] > > > > This email was top-quality and very well done by you guys. > > > > Matthew. > > > > Regards, > Vladimir Thanks for the feedback guys. Looks like we need to find a way to get the ability to have either 32-bit or 64-bit LPM entries supported, as well as the additional enhancements proposed :-) We'll see what we can do in 2.3 timeframe. Regards, /Bruce