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 DD3A71B00B for ; Fri, 15 Dec 2017 13:28:35 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id r78so17226500wme.5 for ; Fri, 15 Dec 2017 04:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:user-agent; bh=ckJvgPEidtXBeuPVj/nQ4wDcVSDLoTSdZVv5Yriju7g=; b=j4mJBunszfBK+//14HSJA4LgCt+KHmUPFLky8/fWhwlZcfe+sF6Q6RZJPI5Ig/9YLm A8TIBDX7oxSf79rRKTn8qr7SCcbfvWEG455OiBHsie8/FAyBfmwy2I2CzUUDIV8VEHRQ owWH1LMxbxGE1mwd5o54pp8m495f5T0F2j0qdyQcccEvy0aszXWfNZLNxtArhHJCoPdd fpKVk9fuOBfKh5SDYn/tm2tkZzasQx2cI7qQqT4EUOkVI/773f4QfOIiyxdzsUhs1pd2 WK8iWJ3sJXZzpxIiMjUUdaTdHRvpPcZI3EI5FmS+dY+jqM2SNdQ4H2LPIEHawmQPH4X+ uSgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:user-agent; bh=ckJvgPEidtXBeuPVj/nQ4wDcVSDLoTSdZVv5Yriju7g=; b=PMIwMCWyxJIxdTKmdx4OtMIrNQ2w+KXe/ddTTYxJiU+86WgwSH6m6RMWvpjfKbk9Xd LmjlBcbeGupcZC7m2Hhl+UnzTGcUVbLU2Z7pnrZrYTmjUqjWEpxkKoTjg4LopLfNoFHu 3GCYfP2tZGZ/fZDDWkc0KYv9p/ZtVbeJlNImd8env5QIbXNjdLXQCOgvM2cqhX/gjdzg tGiCiolr1Zw4PLTJ8zvq+fxj+BUyTeHl+5KM37LHvMpcOy6KJAVkpdoQNjvi0A8bGgcK RP1noeDdNBpQ6mvUVFQ8ns5oVgedd5VwGMRVIiQ+kp9+bbpqFRV1CNBdbcHuwAHBQgLN D5bg== X-Gm-Message-State: AKGB3mJ/c4ky8EgMtmtP5AMXSIBeIaKNUPLL8cboRAr6Nn0CHAsx7QMG JR8UnUMZ0wbpjeejCKOYXIhy X-Google-Smtp-Source: ACJfBosxkNZ736gZKAWWraR0mJtYili+Yd63vUYjOeYsmQCFby7X7z/AxPlKVMwe4/dW8bQ1XpDFzA== X-Received: by 10.28.11.6 with SMTP id 6mr4591957wml.135.1513340915563; Fri, 15 Dec 2017 04:28:35 -0800 (PST) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id q32sm2056273wrb.95.2017.12.15.04.28.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Dec 2017 04:28:34 -0800 (PST) Date: Fri, 15 Dec 2017 13:29:10 +0100 From: Nelio Laranjeiro To: Shally.Verma@cavium.com, Mahipal.Challa@cavium.com, NarayanaPrasad.Athreya@cavium.com, pablo.de.lara.guarch@intel.com, fiona.trahe@intel.com, Declan Doherty , Akhil Goyal , anoob.joseph@caviumnetworks.com, Thomas Monjalon , Olivier Matz , Adrien Mazarguil Cc: dev@dpdk.org Message-ID: <20171215122910.e6szzcpn7ybate5h@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: NeoMutt/20170113 (1.7.2) Subject: [dpdk-dev] Inline/look-aside transformation API (Crypto, IPsec, VLAN insertion, Compression, ...) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 12:28:36 -0000 Hi all, I would like to raise an issue to open a more generic discussion, This concern comes from the issues I am currently facing with rte_security where there will be 3 different configuration code paths and 2 different datapath depending on the NIC capability [1][2]. This bring a real complexity for an application as it will have to use different code paths for each device/port. This brings a more general issue concerning such devices which are able to offload any kind of transformation. For that, new API are starting to appear (rte_security, Compression) from a generic point of view, it is a transformation API which is necessary with transformation actions. Looking into this last point, seems we already have a generic way to handle it through the generic flow API which matches a pattern and make actions on it, those actions can finally be something like: xfrm-crypto algo hashkey salt offset or xfrm-compress algo ... It could also be used to make multiple transformation on a single flow like: xfrm-vlan tci 10 / xfrm-compress ... / xfrm-ipsec-encap ... / xfrm-crypto ... .................................... / xfrm-macsec-encap ... / xfrm-crypto ... The missing point seems to be the metadata such offloads may need to handle the job which is per packet. For such situation we could eventually use a pointer to a list of offloads request passing among the packet directly inside the mbuf or in a new argument of {rx,tx}_burst(). This part is more complex to design to avoid huge performance degradation in both applications and PMD. The point is, adding new offload bits in the mbuf are not unlimited whereas the possibilities of those "smart" NIC are, at some moment we will be stuck. We can avoid it with such kind of approach. Pros: - Adding new actions/offloads don't break API/ABI. - No need for offload capabilities bits/API, an offload request through rte_flow is enough to know both: offload capabilities and if it is applicable on the pattern. - An easier and flexible way to combine transformations. This is still an idea which needs more meditation. Thoughts? Thanks, [1] https://dpdk.org/browse/dpdk/tree/examples/ipsec-secgw/ipsec.c#n50 [2] https://dpdk.org/ml/archives/dev/2017-December/083983.html -- Nélio Laranjeiro 6WIND