From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by dpdk.org (Postfix) with ESMTP id 95F622A58 for ; Wed, 28 Sep 2016 15:03:21 +0200 (CEST) Received: by mail-lf0-f54.google.com with SMTP id l131so51024529lfl.2 for ; Wed, 28 Sep 2016 06:03:21 -0700 (PDT) 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:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=1knrtIUrbhr5L3Hj9E7Y4/Z3fmJ0xH1G5sjtU+R0EhA=; b=Zg/BE+VeHo8IwmDu+Dz6N/YvMNPrShlKEZJK32Byb7zmkHB8bH/cdlpJ0iu66HklxW tVQspGS1cZ7MXd7ZmmGKcU6RrLGc/ajSfeJwXVhnnP4JgvAtu/sMr13dpLo0Al0Z5Iem r5J3fMjfwkzjrqtgeFpGORz2nl7OglTr0HsQ7+V4GlCi+n/qJZQDlZ18zp7NbgGY/k1v CfD1xGwfGnvMp8XFQsahdLrLuoJTeYPe2D9WLzVIXI5zmorPVSBayS6zuC2XGOcwBr1q 4JKggaMPZ8uyXMObLJYb3pDrZfIYYqTGygFoZOLW78vXEeup47Sq+ajXmeO0k3NDT7To om0w== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=1knrtIUrbhr5L3Hj9E7Y4/Z3fmJ0xH1G5sjtU+R0EhA=; b=ZCylciZxfhVJfQQC9+m63yrMBavTH+Qm/ZfvyAiLURDpFox/tKQ9+tSgBUc0VEzNGp XLu+SctikEODJlWaCuzALKa0/RU0UwmQTlDe08vx0BfZm9xMDejeZw/nDJzkatwEgbB/ IHBQwF7BmRcr1wlilKiqRw0Rtef+wlr+yVCjsd3Yj/3qAqRxzEwHPTYu04yk9TrQORqg NddWvQGMOVWvMH3tTxwpwoKG+ah1LCiCkwbiBDeFvPl7IdRlHvuKheCd/9LKuBS/cSGn 1tt4NCUO4+CLuOL1dEjgIB5C5FVstQjiLkKD/GqyC7nww1Mfw2jIXCGa9sk3QKTBvqon O4Zw== X-Gm-Message-State: AA6/9RkbAta+T081LGtNaJlcrb7ObZFyTnf4xHZ1f7DZk6kZcylLvLLBK2I8Kt/2y/+zj4X1 X-Received: by 10.194.51.5 with SMTP id g5mr31984244wjo.68.1475067801182; Wed, 28 Sep 2016 06:03:21 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id bj8sm8273484wjc.49.2016.09.28.06.03.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 06:03:20 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: "Iremonger, Bernard" , "Richardson, Bruce" , dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Date: Wed, 28 Sep 2016 15:03:18 +0200 Message-ID: <1918603.2PG7Ygo6cR@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0BC0A3@irsmsx105.ger.corp.intel.com> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <8CEF83825BEC744B83065625E567D7C21A08D86D@IRSMSX108.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0BC0A3@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management 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: Wed, 28 Sep 2016 13:03:21 -0000 2016-09-28 11:23, Ananyev, Konstantin: > If we this way (force user to include driver specific headers and call driver specific functions), > how you guys plan to make this functionality available for multiple driver types. Multiple drivers won't have exactly the same specific features. But yes, there are some things common to several Intel NICs. > From discussion with Bernard understand that customers would need similar functionality for i40e. > Does it mean that they'll have to re-implement this part of their code again? > Or would have to create (and maintain) their own shim layer that would provide some s of abstraction? > Basically their own version of rte_ethdev? No definitive answer. But we can argue the contrary: how to handle a generic API which is implemented only in 1 or 2 drivers? If the application tries to use it, we can imagine that a specific range of hardware is expected. I think it is an important question. Previously we had the issue of having some API which are too specific and need a rework to be used with other NICs. In order to avoid such rework and API break, we can try to make them available in a driver-specific or vendor-specific staging area, waiting for a later generalization.