From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 7DAFC2C58 for <dev@dpdk.org>; Thu, 14 Sep 2017 10:02:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2751D20C01; Thu, 14 Sep 2017 04:02:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 14 Sep 2017 04:02:28 -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=iMQKqiR3+TdZC86 ZK/h5KSfq3MKd1AlAGXWUbsoIxM0=; b=HflWzqKKcc8mFkJcm9eRgUcOfUzsSt2 EjMCxJ3ChBmnCdpHysh9zU6TRadd8PldygFPc1IlqYYvM1yb2+YsjSWG+6qm2j4r GKvlhOKhgeNDrRJpj2qHN+53sxJTYUIioImhsmxOBNn5Gyl1qfVEmVtoOlyQJyZP iu0tZohgf8IA= 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=iMQKqiR3+TdZC86ZK/h5KSfq3MKd1AlAGXWUbsoIxM0=; b=Z1WQ34Gx hCnwWpZsS2IFrSsW7FTnN9sHHKUzEYbbYZLh+/c0lQNTXR68U6K85P0z2XIcgjr/ +RAlgrG5CXMU0ORapcXn1HakbOeR3tQPmXohznqYwUZ3e8QjeuSNHLyBZKOwW73X cpAIRMxr+uRIF8r9/FT8pnM4CyjePQIZjlmUc+lMDdt0ZTyXhrnFsuY/SeD4B8zP CVBcSCi3R4/uYJMMoLsf4+XRUBcPAF2Gjp9pp2fG6BaVAVynZVElsrel26CgDksN /0f+cVQilvgNTf+DbB3CIXRsqbGSf6x7Q3qEf7dq685//OiC58Pw6UZDjgpbxLNf yLtkUJFi/YrmVQ== X-ME-Sender: <xms:lDe6WX4cOgExx82VS8u20OEKQKyCSznNtyxCKRlxKNVwLGHrTXxBtw> X-Sasl-enc: IPESgFWB4+n6eh97hmWC6qp58dUqUi6xA18JQCzXsUmU 1505376147 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C5EB524009; Thu, 14 Sep 2017 04:02:27 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> Cc: stephen@networkplumber.org, dev@dpdk.org, Shahaf Shuler <shahafs@mellanox.com> Date: Thu, 14 Sep 2017 10:02:26 +0200 Message-ID: <6120098.SpXJOblVKo@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F24AA9D@irsmsx105.ger.corp.intel.com> References: <cover.1504508374.git.shahafs@mellanox.com> <12544923.ZPp1eIik3W@xps> <2601191342CEEE43887BDE71AB9772584F24AA9D@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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 14 Sep 2017 08:02:28 -0000 13/09/2017 23:42, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 13/09/2017 14:56, Ananyev, Konstantin: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Konstantin, I would like your opinion about the proposal below. > > It is about making on the fly configuration more generic. > > You say it is possible to configure VLAN on the fly, > > and I think we should make it possible for other offload features. > > It would be a good thing, but I don't think it is possible for all offloads. > For some of them you still have to stop the queue(port) first. > > Also I am not sure what exactly do you propose? > Is that something like that: > - wipe existing offload bitfileds from rte_eth_rxmode (already done by Shahaf) > - Instead of uint64_t offloads inside both rte_eth_rxmode and te_eth_rxconf > Introduce new functions: > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t offload_mask); > > uint64_t rte_eth_get_port_rx_offload(portid); > uint64_t rte_eth_set_queue_rx_offload(portid, queueid); > > And add new fileds: > rx_offload_port_dynamic_capa > rx_offload_queue_dynamic_capa > inside rte_eth_dev_info. > > And it would be user responsibility to call set_port/queue_rx_offload() > somewhere before dev_start() for static offloads. > ? Yes exactly. > If so, then it seems reasonable to me. Good, thank you > > > > 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?