From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id E248E3195 for ; Tue, 15 Dec 2015 09:50:44 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id n186so154224716wmn.1 for ; Tue, 15 Dec 2015 00:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZB3Eb0r+tUBcOwNqsT8bY9khg63E/kKGxslWhHb3puY=; b=VcX/A5LvMvhJe4POxtEdIFPEtrekqW/4a9B8BVCF7VAwt4KOB4OUozVh+zs7SQMCTl L8e81axMsZofkQqTLIZ76D5iC6K5q0DHCi5esO1BBKDZtvmsWag91krqOAigTOunBLOm 8D7Bp8GbKT0q9+IpOFM/bDXGoK+D5RQzXKYGFAzWmoAkFlzZy74z4tfdqcZNdQqTuL6S 5NYlkVL8QBpuw8jmigfP1y6qewOun2CW2HsL8zOaBu/GDR8RrDiGfb2XNy4uHtDAKPQ7 40u7WMDWD8ADrjVZjg1EMlWbwoyF1zNOHkvEh6ir1ldWbPgsPZupyAkjQuG1zXgCjchY 3RjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZB3Eb0r+tUBcOwNqsT8bY9khg63E/kKGxslWhHb3puY=; b=i7riv9gRy67L5I3nHQvMNq7hQjqJ+IOPWcSZtV7xU19bDzUYebJOMEYPa6XGAUxkyH mG7ZamXSSQJqbGFNClJCVRv3Q6cNeb3jPTzOLslLVgNhp/gH3GJSMNXkJ67SSG2IfCK7 02TlnJu/0DRcCo9b1dwK3tS4l+loW9iQ1WrnTht4Q51B4oLXCVLZb+zFZT3iiF6KYQxV zDeiTr0wIUEZgycrTpFQob3mZyBxz57rbbLLHLmbcHUvwohmUSaC2F3RmXGvQA2i//hf oLe+5aEhJsEttJu5zVI2SZMoAq0yWFYQYZQ0MBXgZImct8jSUg+71pKchvV3jWO3vIRa 1y6A== X-Gm-Message-State: ALoCoQnyT02P2haiGSLl34ee4/bn4/bpSjTVemBO9DWBvzCvPA5MLLKtMQuHj0cei20HYdFW5+LdH8vI0N0lhDb8qelgmSSL0Q== X-Received: by 10.28.125.201 with SMTP id y192mr3215118wmc.23.1450169444756; Tue, 15 Dec 2015 00:50:44 -0800 (PST) Received: from [10.16.0.189] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id u139sm19845410wmu.22.2015.12.15.00.50.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 00:50:43 -0800 (PST) Message-ID: <566FD452.6060309@6wind.com> Date: Tue, 15 Dec 2015 09:50:26 +0100 From: Ivan Boule User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Jijiang Liu References: <1450079331-28139-1-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1450079331-28139-1-git-send-email-jijiang.liu@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf 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: Tue, 15 Dec 2015 08:50:45 -0000 On 12/14/2015 08:48 AM, Jijiang Liu wrote: > In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration. > > And tunneling packet encapsulation operation will benifit from the change. > > There are more descriptions for the ABI changes below, > > The struct 'rte_eth_tunnel_conf' is a new, its defination like below, > struct rte_eth_tunnel_conf { > uint16_t tx_queue; > uint16_t filter_type; > struct rte_eth_tunnel_flow flow_tnl; > }; > > The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1]. > > [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html. > > The change of struct 'rte_eth_conf' like below, but it have not finalized yet. > struct rte_eth_conf { > ... > uint32_t dcb_capability_en; > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */ > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */ > struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT]; > /**< Tunnel configuration. */ > }; > > v2 change: > Add more description for the change. > > v3 change: > Change ABI announcement description. > > Signed-off-by: Jijiang Liu > ---cmdline.c > doc/guides/rel_notes/deprecation.rst | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index 5c458f2..9dbe89e 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -23,3 +23,9 @@ Deprecation Notices > * ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support > tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI > changes, but release 2.3 will, and no backwards compatibility is planned. > + > +* ABI changes are planned for the struct rte_eth_conf in order to add 'tunnel_conf' variable > + in the struct to store tunnel configuration when using new API rte_eth_dev_tunnel_configure > + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * tunnel_conf) to configure > + tunnel flow and classification information. The release 2.2 does not contain these ABI change, > + but release 2.3 will, and no backward compatibility is planned. > Hi Jijiang, Can you provide a real use case - I mean an example of a real network application - that really needs to save tunnel configurations in a data structure associated with a NIC port? Firstly, if the only usage is to enable applications to retrieve tunnel configurations, then you are simply growing the size of the per-port structure with tunnel configurations, and imposing it to every DPDK application. You impose it to those applications that don't care about tunneling, but also to those applications which do care, but which prefer to have their own representation of ports where they store everything they need to. If the tunnel configuration is also used for other purposes, then it must be precisely described what happens with the saved tunnel configuration when the application changes the state of a port. This is the case for instance when the application reconfigures the number of RX queues of a port. Who is responsible for checking that some tunnels won't be matched anymore? Who is responsible for dropping/invalidating the saved tunnel configuration, if such operations must be performed? This list is likely to be not exhaustive, of course. More globally, all side-effects of saving the tunnel configuration must be considered and addressed in a coherent way and in an easy-to-use approach. By the way, as far as I know, the Linux kernel does not [need to] save tunnel data or ARP entries behind "netdevice" structures. PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field should be named "rx_queue" instead of "tx_queue". Regards, Ivan -- Ivan Boule 6WIND Development Engineer