From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 347A6A04A5; Wed, 9 Feb 2022 14:55:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF5E641143; Wed, 9 Feb 2022 14:55:01 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id CC6E940140 for ; Wed, 9 Feb 2022 14:55:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644414901; x=1675950901; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OXdmItX+WdaY4D1sST8BIgCYSRMHHAAVGV718nbqbOw=; b=eS/ckMtphJ/ACnS0W3USKNd5+qLSXMsCMtpk7KG520mJzKuga3qgXELE TGf6FJE9tHiokDeaBLzS8ag7FRjwAwZ4lrg4j3qALCDEXZoTvA1r6nHEJ JBR7bmWQ381/ZCUf9qk+n3VpVNxHLpx8xrtRLQZc0f9aWO7pbqbXy+ku2 tK7tVvFFRpjX6bZATHBOUxkd+WPILVHTUmp/PwI/cGH3ChMHVg/+Ar6CZ InbD0ZjGD68NOQeG2h8Aro2AZB36HR4bWdgBqC5fOaMfjDLOnV2HjlLPr Vm/HcCAfzTwx9yynT8z4gN3pkH7pUAnuGf0R7Qb6MLBJIi2HZZvOlUujx A==; X-IronPort-AV: E=McAfee;i="6200,9189,10252"; a="273743292" X-IronPort-AV: E=Sophos;i="5.88,355,1635231600"; d="scan'208";a="273743292" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 05:54:59 -0800 X-IronPort-AV: E=Sophos;i="5.88,355,1635231600"; d="scan'208";a="525993897" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.19.97]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Feb 2022 05:54:58 -0800 Date: Wed, 9 Feb 2022 13:54:54 +0000 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: Stephen Hemminger , "Medvedkin, Vladimir" , "Morrissey, Sean" , "dev@dpdk.org" Subject: Re: [PATCH v5 0/2] Add config file support for l3fwd Message-ID: References: <20220126124459.2469838-1-sean.morrissey@intel.com> <20220204195905.449192-1-sean.morrissey@intel.com> <20220204142636.6250f05c@hermes.local> <20220207190419.2a1ca44b@hermes.local> <5a01520b-b85a-02c7-67eb-5a7119e46ada@intel.com> <20220208094904.5ca9db4c@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Feb 09, 2022 at 12:00:40PM +0000, Ananyev, Konstantin wrote: > > > > > >> Or have a generic library for reading LPM entries. L3fwd is supposed > > > >> to be as small as possible (it no longer is), and the real work should > > > >> be done by libraries to make it easier to build other applications. > > > > > > > > I never heard users ask about such thing, > > > > but if there is a demand for that, then I suppose it could be considered. > > > > CC-ing LPM/FIB maintainers to comment. > > > > Though I believe it should be a subject of separate patch and discussion > > > > (I think many questions will arise - what format should be, how to support > > > > different types of user-data, to make it generic enough, etc.). > > > > > > Agree, it is very application specific, so it could be really difficult > > > to make it generic. > > > > But several other also have LPM tables, so why not have common code for other applications. > > > > examples/l3fwd-power/main.c > > examples/ipsec-secgw/rt.c > > examples/ip_fragmentation/main.c > > examples/l3fwd/l3fwd_lpm.c > > examples/ip_reassembly/main.c > > Ah yes, that's good point. > All these examples (except ipsec-secgw) started as l3fwd clones, > so all of them have hard-coded LPM (and EM) tables too. > Yes it would be good thing to address that problem too, > and have some common code (and common routes file format) for all of them. > I don't know is that a good idea to introduce parse file function in LPM/FIB library > itself, might be better to have something like examples/common/lpm_parse*. I think it really depends on whether you are planning on implementing a general config file for the application, or whether the file(s) will only contain the LPM/FIB routing entries. If the plan is reading just the routing entries from file, then I definitely think that it might be something that would be generally useful inside the library itself. If it's a more general config file with other app settings in it, then an examples-only parse function/file would make more sense. > Anyway, this is an extra effort, and I think no-one has time for it in 22.03 timeframe. > My suggestion would be for 22.03 go ahead with current l3fwd patches, > then later we can consider to make it common and update other examples. > Konstantin