From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 27519689B for ; Wed, 11 Jan 2017 18:32:57 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id c85so163919011wmi.1 for ; Wed, 11 Jan 2017 09:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jV5RNwOVbCH3Yo4ykyYUgRgqfF3j97/yuo41wIrdf3Y=; b=JhajHUk8wvrcJ1ZLk1HxzjkfJEioE95cqbScCccOQrARqb/YBrDpL3CIRFpP7mhFW/ jEyulpLkxp9t3S/dvKRL6w0QYPugzrEVENf4eSaJglE7qyZDlrKFTmSvPNJNjaVa7fC2 q2krEYRb4EItYRV6h/0DkIeHVRpU/AwebqUNGLE9jCO4dgzkZWO//i6VwWGVz08y0z41 awe74re3KwNVk/EJ+EvowB0/OJIr9eb2q1naAjyYQGchJzA+Wk2Dm03dBBh5dcnb4Bkt X2rhsDhWtnK/48jn9Gk45uFh4S6J54eiIdMbiH0PesvXCReg94LtqDSDe8qQ/8TqNu9A CvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jV5RNwOVbCH3Yo4ykyYUgRgqfF3j97/yuo41wIrdf3Y=; b=cWOORYpDSRUvLHKsc8E7Ziml/hC1NQdgfNOULgz7ioDRSpY8i2YUDyfcH8LDC87uwv b79lHz+wulvKGnOefWKtYamvujQmlfTkIS32Ng2or8769Rd1OkgJImU4Pv9Ebl2F07H6 bA2g5p0rPwDLEj35c0z9Dq9bxnHdDjjJAhzvU6HEU7BBB7i9ygutX0PFdoWYXUdEdAGd VfyN55FCE6pnNTyO+LHwEgTm5oLR1lDxIumXgapsEmS7VjvmhJZpzNKI4cC5fn2MFVGd i+SGlIUQ07k5FNoSbfjZE0GalAk7Ai4TN6uW3Rio5BQEcyOkZz21m7z/XLxnrBvbjPh8 fZLQ== X-Gm-Message-State: AIkVDXKquuW9U1ShUuapujcfPLHxJPJao/nqJx7YIAeVORZw2lskOD2IBFlnDMbwpCV0sBas X-Received: by 10.223.143.48 with SMTP id p45mr4417874wrb.33.1484155976848; Wed, 11 Jan 2017 09:32:56 -0800 (PST) Received: from glumotte.dev.6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id bc2sm9505222wjb.38.2017.01.11.09.32.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jan 2017 09:32:56 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Wed, 11 Jan 2017 18:32:48 +0100 To: Thomas Monjalon Cc: Tiwei Bie , "Ananyev, Konstantin" , Adrien Mazarguil , dev@dpdk.org, "Lu, Wenzhuo" , "Mcnamara, John" , olivier.matz@6wind.com, "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170111183248.38a27193@glumotte.dev.6wind.com> In-Reply-To: <1542539.LCBRG7nZDl@xps13> References: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F10241C@irsmsx105.ger.corp.intel.com> <20170109035736.GA11691@debian> <1542539.LCBRG7nZDl@xps13> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API 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: Wed, 11 Jan 2017 17:32:57 -0000 Hi Tiwei, Hi Thomas, On Mon, 09 Jan 2017 12:26:53 +0100, Thomas Monjalon wrote: > 2017-01-09 11:57, Tiwei Bie: > > On Sun, Jan 08, 2017 at 08:39:55PM +0800, Ananyev, Konstantin > > wrote: > > > > Well my first reply to this thread was asking why isn't the > > > > whole API global from the start then? > > > > > > That's good question, and my preference would always be to have > > > the API to configure this feature as generic one. > > > I guess the main reason why it is not right now we don't reach an > > > agreement how this API should look like: > > > http://dpdk.org/ml/archives/dev/2016-September/047810.html > > > But I'll leave it to the author to provide the real reason > > > here. > > > > Yes, currently this work just provided a thin layer over 82599's > > hardware MACsec offload support to allow users configure 82599's > > MACsec offload engine. The current API may be too specific and may > > need a rework to be used with other NICs. > > I think it is a really good approach to start such API privately in a > driver. It will give us more time and experience to design a proper > generic API. > > Regarding the mbuf flag, it looks straight-forward, and as it is IEEE > standardized, I do not see any objection to add it now. > However, I will wait for the approval of Olivier - as maintainer of > mbuf. > Generally speaking, we have to be careful when introducing new mbuf flags, since we don't have so much of them (~25 remaining out of 64, which mean we may run out of them in 3-4 years). In this particular case, despite the flag is added for an ixgbe-specific API, when MACsec will be implemented on another PMD, the exact same flag would also be needed. That's the same for the ethdev capability flag. Moreover, as Thomas stated, it's a standardized protocol so it's legitimate to have it included in rte_mbuf.h. For me, having PMD-specific APIs for a new feature is not a problem, but I think we should try to have a generic API as soon as the feature is supported by several PMDs. Regards, Olivier