From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 0D703234 for ; Thu, 24 Dec 2015 14:28:18 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id l126so179942154wml.1 for ; Thu, 24 Dec 2015 05:28:18 -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=5RGrWYslVXXA9lMsd/+ZBU3M8IlwUh5/caH/h0apxQ8=; b=SD5Sj3BARM+CdAyS5NcdA9j2Pw5lr8uMedP4rfmx/hZsRVZlTVrTd/zCcGcx4iKeRd HlfO/ySwV44gSoqMl/+wshSLaXtA01iM85IVlSU9Z0jxiBWxZcxjWnccmhyaxJy7miHy dtXulTHtaZTphQ3i7gWbEF/shCgtbNCTDYJ9Z+MGNXeHVpbxtTvYd7doyFrpsxpQPzYe hk8BPVB5XrN1kWB4KuhEz6qvnkYH6QShS30dbXh4XnXLQ+RcCXZGeqEy7+UucmSHnYrz lE67Qh7NYcjsCEwuZ4MUWacJVq0C5nLMy8bD3CQZC5MHOYa6j1kbdq18I9Sq4fI/4mw2 JaLg== 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=5RGrWYslVXXA9lMsd/+ZBU3M8IlwUh5/caH/h0apxQ8=; b=F55RXYpxw896u0iqUG0eWSo+Du1YNRNHsv2OQxa9D6GctSBwrXQ80lFjVoDxp5B5FV Qj2pIJ6E6JNoknK2K3tyjVhiVmhSfIEEPacGfAeedOVRCAxYZUyKXE+2MlW9OVMhyJNj kFZxxulVzcSbhEYGIjywBRBc138FDLkZcn+irecl1pKvHP/uCVsRKpmw8u9kb0IRocNZ W2A0ubkSBXi5qXc28SfXgqgJ/j0+hBE9evVjvF/lG0rkjg16vFQwQcRtmGSQvRk5lbJc ZtGlaBbbGfrYiAqEnc/+GeP68l4vO7/Nc9dbVK5ejmJ6jliTvC6AECu5FtNnTU4CxPNg 8rFg== X-Gm-Message-State: ALoCoQlIzjSCTNAvwJcjFYye0y55KLr4APT/Eo5Ggkbt+eoS1sOPkzxLd3iwU6rFQ5RRnUva1K8MJ+Jh1lLM4Z5pT5486GNeLA== X-Received: by 10.194.186.212 with SMTP id fm20mr39296182wjc.16.1450963697796; Thu, 24 Dec 2015 05:28:17 -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 wf8sm9342587wjb.45.2015.12.24.05.28.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Dec 2015 05:28:16 -0800 (PST) Message-ID: <567BF2E0.2010505@6wind.com> Date: Thu, 24 Dec 2015 14:28:00 +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: "Liu, Jijiang" References: <1450079331-28139-1-git-send-email-jijiang.liu@intel.com> <566FD452.6060309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC22BF1A60@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC22BF1A60@SHSMSX101.ccr.corp.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: Thu, 24 Dec 2015 13:28:18 -0000 Hi Jijiang, See my comments inline below prefixewd with IB> Ivan On 12/18/2015 03:00 AM, Liu, Jijiang wrote: > Hi Boule, > >> -----Original Message----- >> From: Ivan Boule [mailto:ivan.boule@6wind.com] >> Sent: Tuesday, December 15, 2015 4:50 PM >> To: Liu, Jijiang >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct >> rte_eth_conf >> >> 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? > > I'm trying to provide a tunneling packet solution in DPDK, which would accelerate de/encapsulation operation of tunneling packet. IB> I was asking for an example of an application that needs to SAVE in the DPDK structure associated with a port a tunnel configuration that it applies to that port. Where does that saved tunnel configuration will participate to the acceleration of decap/encap ops? > > It was described at [1], > [1] http://dpdk.org/ml/archives/dev/2015-December/030283.html > > > Let me provide more details on this, these data structure definition have not fully finalized yet, just for your reference. > We are talking about why tunnel configuration need to be stored. IB? yes :-) > > For NIC A RX process, > VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1] )--->SW decapsulation--->vSwitch--->VM 0 > > For NIC A TX process, > VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encapsulation with info[2]<---vSwitch<---VM 0 > > The[2] information will be got by retrieving the tunnel configuration, if the tunnel configuration is not stored in 'rt_eth_conf', and how to get it? IB> it is assumed that the encapsulation acceleration relies on having this operation done in hardware. Am I wrong? If I am right, then can you tell me which PMD function accesses the saved tunnel configuration? > > Of course, the tunnel configuration is also stored in Application, does it make sense? IB> No. Why store it twice? Are you considering that memory if available for free? > > [1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src port(1000) + outer dst port(2000) + tunnel id(100) > [2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src port(2000) + outr dst port(1000) + tunnel id(100) > >> >> 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. > > About above these question, it is related to design, I will send RFC patch out for review. IB> Do you mean that I will find EXPLICIT answers to those questions in your RFC patch? If so, why not supply them inline ? > >> >> 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. > > It is not related ARP entries, I'm talking about tunnel flow. IB> Really? I did not notice :-) IB> More seriously, what I meant is that it is a good programming practice for an application to have its private representation of low-level objects (a DPDK port here) it uses, and to maintain into it whatever informations it need to. I referred to ARP entries as an example of such informations that can be associated with a port, and thus that might also be saved in a data structure of the DPDK port. Just to outline that there is no end to such approach... > >> PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field >> should be named "rx_queue" instead of "tx_queue". > > No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT]; IB> then, what does the tx_index refer to in in the "rte_eth_tunnel_conf" data structure, and how is it used, and by which DPDK code ? Please, note that by design, the default DPDK rule for the usage of TX queues consists in having DPDK applications assigning each TX queue of a port to a different [paquet processing] core, so that each core can safely transmit paquets through a port in a lockless fashion. Can you guarantee that your tunneling spec. still comply with this rule? Regards, Ivan -- Ivan Boule 6WIND Development Engineer