From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 6E6CA8E8B for ; Mon, 23 Nov 2015 15:18:53 +0100 (CET) Received: by wmuu63 with SMTP id u63so56029220wmu.0 for ; Mon, 23 Nov 2015 06:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=GuSjFQCjThb/wq3Ohp/6AQA9WWww79Qu82KR8luo6z4=; b=pPfiVfNh/9lE7Ho+jNK8u0R8l9RI43D1fONjUgJXAdf3q5hHPYIRTEGV/QsmAPhHxW A8GnDyVsCA5ga3ledwbGmE2FvWt93k3AnWPRc8ZrTSJRcDI1ZY5HFgzlwjgo3Dzs7Fpc zyafTRgS15FsAOovd+t27vNNiqiqFl+twv2qJEWxmw8P4C4mJMe2JwIo9LSI7dxvbwvH ejGDR7P/ASNJf7sdAXOXCWLM2UCKQhc3YZOy6fueofG6Esz0R6Y5goxWKJCLxYEQuNqs wCYqjbxGKa89gDIS5ny1bTww4PK7ntLVgniNwW9pvHtnYf8XiVrFILJ3HR5DynfxsGnI 8b9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=GuSjFQCjThb/wq3Ohp/6AQA9WWww79Qu82KR8luo6z4=; b=mRgyCD2dXsedZW4mdKM3y+bR5y/LTzzBFtEfI90DPOrDuOM5bbqyNsbjOaIK3YBO9b tKR3jE3yTYBWBflAYpPkLR0Yj45MHgGqI7zFbnkCZY8Fzduur4e15yg8nSwMjf4hT7nc hfnPx21/8Z5sbHkBAm/qtSU7Ww9VOEY2RQY/J7oxG6ffk5PMg6Xpk1qHFMKExmgrUkMN 3bDCjPFVaht92VunyOlJZ1g31OPX6I5298BbiS4dOvD/CuaF/qsla1a01+5Y/PfYDCRN bhMVIzLf30ZeluNdBFc3WrgY2PSlGbuFf/ZXYMut/As1nNocdvPAiwcOn+JgNOt6nAH9 RPBw== X-Gm-Message-State: ALoCoQk1IUvLMcwaOCUF/vT2X4nUkRSFUwXrzBfJ7qlBlkr7etRMIXOohrLRy6Okj/4KxHc6oynV X-Received: by 10.28.51.135 with SMTP id z129mr16600794wmz.19.1448288333155; Mon, 23 Nov 2015 06:18:53 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id vu4sm13549426wjc.2.2015.11.23.06.18.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 06:18:52 -0800 (PST) From: Thomas Monjalon To: Olivier MATZ Date: Mon, 23 Nov 2015 15:17:36 +0100 Message-ID: <2891112.tEs81Nm6rs@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56530FB1.8000106@6wind.com> References: <1447176763-19303-1-git-send-email-declan.doherty@intel.com> <565303B8.3080202@intel.com> <56530FB1.8000106@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf 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: Mon, 23 Nov 2015 14:18:53 -0000 2015-11-23 14:08, Olivier MATZ: > 2015-11-23 12:16, Declan Doherty: > > 2015-11-23 11:52, Ananyev, Konstantin: > >> I understand that current API is probably not perfect and might need > >> to be revised in future. > > The problem is that it's not easy to change the dpdk API now. [...] > > Just to re-iterate Konstantin's point above. I'm aware that a number of > > mbuf operations currently are not supported and are not aware of the > > rte_mbuf_offload, but we will be continuing development throughout 2.3 > > and beyond to address this. Also I hope we will get much more community > > feedback and interaction so we can get a more definite feature set for > > the library, and by minimizing the features in this release, it will > > allow more flexibility on how we can develop this part of handling > > offloaded operations and it will limit the ABI issues we will face if it > > turns out we need to change this going forwards. > > I can see the amount of work you've done for making the cryptodev > happen in dpdk. I also recognize that I didn't make comments very early. > > If we really want to have this feature in the next release, maybe there > is a way to mark it as experimental, meaning that the API is subject to > change? What do you think? > > Thomas, any comment? Yes, it is a totally new work and it probably needs more time to have a design working well for most of use cases. As I already discussed with Olivier, I think it should be considered as experimental. It means we can try it but do not consider it as a stable API. So the deprecation process would not apply until the experimental flag is removed. For the release 2.2, it would be better to remove the crypto dependency in mbuf. Do you think it is possible?