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 E86847CBD for ; Wed, 13 Sep 2017 11:27:56 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6652520EF7; Wed, 13 Sep 2017 05:27:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 13 Sep 2017 05:27:56 -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=tH/SC/uH1nyaMMH VscFBNu5VwtRrHXPCC5KCqcEwqQE=; b=I6BkLoJnHsVIrUkCo+MMU/sWVeuwCI1 HLLxKwgeibwE49nAYERr+hzhB+yZoM0Ei4gwxS6YQGuYgS5/czSEo0AJohIPomPU Be3AAWK1LqPsttAiZ/p1LGDTFIY903bwCh9fRr1EDi29AkytmWGcW1XmsNYS7jcq 561OfWfLXVqw= 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=tH/SC/uH1nyaMMHVscFBNu5VwtRrHXPCC5KCqcEwqQE=; b=CFZ+maFh 8TTvrKmhM4iyCxxpWssou80z+dp4zywPhV7SqEqAFOE3wDDnrcQ+C5UROoxU3060 pWPW3h412/1CVi4z/jVG+FnesGWi9R78UeeMrAFrJTyjvjyNr8uPtm7UNudNJVE6 /im0CHZZsNa5YPuAJQvZ9vYuG4pmnwQSBq+m3N5E9f3NKKImcEWC7vmoOn/IJTf5 VtMAeVl1rc4YScCAD54tJJjPRKvKQKLu0HANRfuMiZFBs636I68Gwe0d5H6c4fxP ig+wlF8DIKzQcZLxJI7kFGx5SYA+udyVdXVYPhRmV1WLiN2xXwSYb2/6Fgfnfe05 RwsvBnE4E7x/ag== X-ME-Sender: X-Sasl-enc: 2p6JpSXLNMj4fquHYKTdfyhjxfAXZ6cJLO611gPJOmCK 1505294876 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 17A2624A5D; Wed, 13 Sep 2017 05:27:56 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , Shahaf Shuler Cc: dev@dpdk.org, stephen@networkplumber.org Date: Wed, 13 Sep 2017 11:27:55 +0200 Message-ID: <2632317.9dDdYF2F86@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F2480E8@irsmsx105.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772584F2480E8@irsmsx105.ger.corp.intel.com> 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 09:27:57 -0000 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). More comments below 06/09/2017 11:33, Ananyev, Konstantin: > From: Shahaf Shuler [mailto:shahafs@mellanox.com] > > Tuesday, September 5, 2017 6:31 PM, Ananyev, Konstantin: > > > > > > > > > In fact, right now it is possible to query/change these 3 > > > > > > > > > vlan offload flags on the fly (after dev_start) on port > > > > > > > > > basis by > > > > > rte_eth_dev_(get|set)_vlan_offload API. > > > > > > > > Regarding this API from ethdev. > > > > > > > > So this seems like a hack on ethdev. Currently there are 2 ways for user to > > > set Rx vlan offloads. > > > > One is through dev_configure which require the ports to be stopped. The > > > other is this API which can set even if the port is started. > > > > > > Yes there is an ability to enable/disable VLAN offloads without > > > stop/reconfigure the device. > > > Though I wouldn't call it 'a hack'. > > > From my perspective - it is a useful feature. > > > Same as it is possible in some cases to change MTU without stopping device, > > > etc. I think the function rte_eth_dev_configure(), which set up several things at a time, is a very bad idea from API perspective. In the VLAN example, we should have only one function to set this offload. And the PMD should advertise the capability of configuring VLAN on the fly. This function should return an error if called on the fly (started state) and PMD does not support it. > > > Consider scenario when PF has a corresponding VFs (PF is controlled by > > > DPDK) Right now (at least with Intel HW) it is possible to: > > > > > > struct rte_eth_conf dev_conf; > > > dev_conf. rxmode.hw_vlan_filter = 1; > > > ... > > > rte_eth_dev_configure(pf_port_id, 0, 0, &dev_conf); > > > rte_eth_dev_start(pf_port_id); > > > > > > In that scenario I don't have any RX/TX queues configured. > > > Though I still able to enable vlan filter, and it would work correctly for VFs. > > > Same for other per-port offloads. > > > > For the PF - enabling vlan filtering without any queues means nothing. The PF can receive no traffic, what different does it makes the vlan > > filtering is set? > > For the VF - I assume it will have queues, therefore for it vlan filtering has a meaning. However as I said above, the VF has the vlan filter > > because in intel this is per-device offload, so this is not a good example. > > Yes it is a per-device offload, and right now it is possible to enable/disable it via > dev_confgiure(); dev_start(); > without configuring/starting any RX/TX queues. > That's an ability I'd like to preserve. > So from my perspective it is a perfectly valid example. It is configuring VFs by setting the PF. Where is it documented? It looks to me as a device-specific side effect.