From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 2A3B11B424 for ; Sun, 15 Apr 2018 12:37:30 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9ADCD230FB; Sun, 15 Apr 2018 06:37:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 15 Apr 2018 06:37:29 -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; s=mesmtp; bh=h+yniHzoYcd89Tsk1scGm2Dqjd TorTac+WulmtTSdXk=; b=lvrI2V+6y5GlLhaBPosu6eLqy5KrwuNlxFazIGiSkS 5u7p5E3b9hO7M6fbJccmZftbfIM9RfsQgbgoubsQEdm6u0/nkv8lTMbNQRSIc7lD GjHTRf/xYqlFamZE7MBY8qV1Ls1xY1hE6uT0Q8TrwSov5kcPe8AhDnhcR9Kxdr2m g= 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; s=fm2; bh=h+yniH zoYcd89Tsk1scGm2DqjdTorTac+WulmtTSdXk=; b=b2xl21nTHraMNqsJZoe17K do6qrdY8pNGOvY8UFa7xOgJT6Jc2CP6bxUnBTpP2J/iQNPKIGGbEII4ftu/YtLWx zbbF+zfn+eZBjrnCCZvsKEvQ+uD/gSYDCyMQ7dP5SPduC+vG6D1MDt4VcLyGE1Kx 4qzOINKqYUYBEObDWmqPRutFh7dnLmdZP4bjr5iL9bBLs52/7YWAePNDfbHE8ylX hIoQ+nTe0bpo5XwbmYLA6CkBk7jAf4cUocr+Mr4w/UilR1vLtY6GW2QPhOP1kvS4 dDhkm60BSIA/NLawZTjbvYPq4gSnzMNWz+l70ok+qLqv/hPstVLEePDd6Ee7UGpw == X-ME-Sender: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id E544A10252; Sun, 15 Apr 2018 06:37:28 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Wei Dai Cc: dev@dpdk.org Date: Sun, 15 Apr 2018 12:37:27 +0200 Message-ID: <8859984.fs3nS3s03y@xps> In-Reply-To: <7148c9d5-cf94-66db-1a1f-42c522c3edc0@intel.com> References: <1517493186-6687-1-git-send-email-wei.dai@intel.com> <20180328085709.28310-1-wei.dai@intel.com> <7148c9d5-cf94-66db-1a1f-42c522c3edc0@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: check Rx/Tx offloads 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: Sun, 15 Apr 2018 10:37:30 -0000 13/04/2018 19:31, Ferruh Yigit: > On 3/28/2018 9:57 AM, Wei Dai wrote: > > This patch check if a requested offloading > > is supported in the device capability. > > A per port offloading feature should be enabled or > > disabled at same time in both rte_eth_dev_configure( ) > > and rte_eth_rx_queue_setup( )/rte_eth_tx_queue_setup( ). > > This patch check if a per port offloading flag has > > same configuration in rte_eth_dev_configure( ) and > > rte_eth_rx_queue_setup( )/rte_eth_tx_queue_setup( ). > > This patch can make such checking in a common way in > > rte_ethdev layer to avoid same checking in underlying PMD. > > I think it is good idea to move common check to the abstraction layer as much as > possible. > > But for this case we are targeting an API change in rc2, I believe better wait > that API change for this update. I think Wei could implement some filtering of offload flags: If an offload is already enabled at port level, we can filter out them when enabling again at queue level. By removing such repetition in ethdev, before calling the PMD op, the PMD does not need to bother for offloads enabled twice.