From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id E19817CB6 for ; Wed, 13 Sep 2017 14:41:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 39EE520C45; Wed, 13 Sep 2017 08:41:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 13 Sep 2017 08:41:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=s86u6FThubKZIgk KoAXFwLlrD+RUx6glQgLlUcZ26mM=; b=cEpIR1doL2+PGtNNED/ElyM4MHrmBkq 6L5FuPVtJ1y3cHbHuuZDMsyCNu47mIh8MKRPvsb0ze7G9shRwHImHGtQLQ5Si1r9 5+u4ZkLKVKEPRco+dh/YrBJ1XtB6V4DI2V8A/myI1xL5JcQXgOKhAMf3pGGoOvn1 2ONvOd8XFLAg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=s86u6FThubKZIgkKoAXFwLlrD+RUx6glQgLlUcZ26mM=; b=AukIBxuo PUjITHmeaiWSTICAwVUc9czBCLxQoqtkiUB2jDOWZgIXR89FDoHC5ZoGS40caD0s XutyAAeST/BtB+M9yvCtwhAX7j6ed2B2ft+ZZRUjpRNDE4zXwJlgAVuMkSUhNRzs dRYfYaJTqIdnGYlwy0Z9JZTIStmiw4NitUWlv4qIRkW/ug/B7W6v7GQ1y7aezWb5 rtZmQVnvEIH62E1/5adn4Hr9g2UI/jWeMmLIkOI1/5xPs59651R3QClL3TuADtX0 E4yiVK8wXC4pg+YncXZlYom5sO3MBlfqoMNbfUN33A0+K7VR4Ip6yWTfzdi/u1pS ASFFHfDThQixpw== X-ME-Sender: X-Sasl-enc: u0ZnLTUDiQYdLmGMzV7yE0VhTtRo8/9JaedjDHIjbkbQ 1505306507 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DDED87FA8B; Wed, 13 Sep 2017 08:41:47 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org, Shahaf Shuler Cc: "Ananyev, Konstantin" , stephen@networkplumber.org Date: Wed, 13 Sep 2017 14:41:47 +0200 Message-ID: <1868308.cPa78Soq0s@xps> In-Reply-To: References: <2632317.9dDdYF2F86@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads 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, 13 Sep 2017 12:41:49 -0000 13/09/2017 13:16, Shahaf Shuler: > Wednesday, September 13, 2017 12:28 PM, Thomas Monjalon: > > I still think we must streamline ethdev API instead of complexifying. > > We should drop the big "configure everything" and configure offloads one by > > one, and per queue (the finer grain). > > The issue is, that there is some functionality which cannot be achieved when configuring offload per queue. > For example - vlan filter on intel NICs. The PF can set it even without creating a single queue, in order to enable it for the VFs. As it is a device-specific - not documented - side effect, I won't consider it. However I understand it may be better to be able to configure per-port offloads with a dedicated per-port function. I agree with the approach of the v3 of this series. Let me give my overview of offloads: We have simple offloads which are configured by just setting a flag. The same flag can be set per-port or per-queue. This offload can be set before starting or on the fly. We currently have no generic way to set it on the fly. We have also more complicate offloads which require more configuration. They are set with the rte_flow API. They can be per-port, per-queue, on the fly or not (AFAIK). I think we must discuss "on the fly" capability. It requires probably to set up simple offloads (flags) with a dedicated function instead of using "configure" and "queue_setup" functions. This new capability can be implemented in a different series. Opinions?