From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by dpdk.org (Postfix) with ESMTP id 8B2982C65 for ; Mon, 21 Mar 2016 16:26:08 +0100 (CET) Received: by mail-oi0-f48.google.com with SMTP id l76so53509707oig.1 for ; Mon, 21 Mar 2016 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CloqqyoiKXhOz4CIRckZuQ9SdlAofKyXfTcGyRA/aog=; b=hU5wz8o0vloTxmp9SqP6Qdl2PRMVyf19YcaAHHof7tXBzE965UtKwdKeupwLyqWW+2 ACgBeGoyDj5X0f9U1L92dRqKa6sGYJGW2nQwf5/HozG7OqGrvTt92Msgm3wqGIJWoVN9 yk3uSC3ICqT+flWShXs27L3BQ11zPYsy8E0I/F7kIjzPu0h31HnsGAtZ8Ie9mRClqGdE h4YFtJ8dT+twPHNENFYXXRwTogBuc6ZVhTWvsdptT/CGsgBljN4bqkl+uSHOxJxZRzUd D/fewuA2VBQVKchz3NlKBK5Pg2gMDjC9nCr7kXKsTPBd4XVmlIf0gKw4NXtvafd+nV7i sKTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CloqqyoiKXhOz4CIRckZuQ9SdlAofKyXfTcGyRA/aog=; b=RFVi0WZfO5ji8eZnQoQkzoAXoBfD0Y8Ut9Zbmc1mJdVwNYpLKjUCvh7K+7M7IJaCgt u1ScUVhSstAy7rJxJO6F32UDkizHr9DwWO1/C5mrlGJFJEbXUTUUX59VWuS1HxnTvTTR BlGL9H+lrYLJ+je/jGyOjhxhEdnVm1H7A9XN7N2vUBAB6qJtfJk7XxoWJ77lMlF/KH0K PHmKsmahAe0dtjSx+bDLtHUJwmOQiFILxuy/Zfgtn0ZiguWHok3t51akodMJCQPloFlU wCevAWqv3LjMdmv8pc8BTzsUFuFGNW9zWFGy5lb34wH+sg8DrHl8k6gEp+tM0wqnAdn2 Mkww== X-Gm-Message-State: AD7BkJLruIYJMpC/9K4m/ioBRaJcuwCGIL1S+tSX3kR/tGg+fbvlm0ptjV1JFAgP2JgOUWxXDS+SLo+yToC7yg== MIME-Version: 1.0 X-Received: by 10.202.214.21 with SMTP id n21mr12272706oig.122.1458573967966; Mon, 21 Mar 2016 08:26:07 -0700 (PDT) Received: by 10.76.115.162 with HTTP; Mon, 21 Mar 2016 08:26:07 -0700 (PDT) In-Reply-To: <20160321145249.GA16732@bricha3-MOBL3> References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13> <29795767.yLuRT7a5hO@xps13> <20160321145249.GA16732@bricha3-MOBL3> Date: Mon, 21 Mar 2016 11:26:07 -0400 Message-ID: From: Kyle Larose To: Bruce Richardson Cc: Thomas Monjalon , "Zhang, Helin" , Stephen Hemminger , dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] DPDK and HW offloads 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, 21 Mar 2016 15:26:08 -0000 On Mon, Mar 21, 2016 at 10:52 AM, Bruce Richardson wrote: > On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote: >> 2016-03-20 14:17, Zhang, Helin: >> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> > > 2016-03-18 10:16, Stephen Hemminger: >> > > > Right now, all those offload features are pretty much unusable in a >> > > > real product without lots and lots of extra codes and huge bug >> > > > surface. It bothers me enough that I would recommend removing much of the >> > > filter/offload/ptype stuff from DPDK! >> > > >> > > One of the biggest challenge is to think about a good filtering API. >> > > The offloading has some interaction with the mbuf struct. >> > > >> > > I would like to suggest rewriting ethdev API by keeping it as is for some time for >> > > compatibility while creating a new one. What about the prefix dpdk_netdev_ to >> > > progressively replace rte_eth_dev? >> > >> > I totally agree with to add new and generic APIs for user applications. But I don't >> > think we need to remove all current APIs. Generic APIs may not support all advanced >> > hardware features, while specific APIs can. Why not support all? One generic APIs for >> > common users, and others APIs for advanced users. >> >> Yes we cannot access to every features of a device through generic API. >> Until now we were trying to add an ethdev API for every features even if it >> is used by only one driver. >> I think we should allow a direct access to the driver by the applications and >> work on generic API only for common features. > > Definite +1. > I think that we need to start pushing driver-specific functionality to get exposed > via a driver's header files. That allow users who want to extract the max > functionality from a particular NIC to do so via those APIs calls, while not > polluting the generic ethdev layer. > What sort of requirements on ABI/API compatibility would this place on the drivers? I would hope that it would be treated like any other public API within DPDK. I don't think this would be too onerous, but it would require that the drivers be designed to deal with it. (I.e. don't just expose any old internal driver function). > On the other hand, I don't like the idea of dpdk_netdev. I think we can work > within the existing rte_eth_dev framework. > > /Bruce >