From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v2 2/2] ethdev: introduce Tx queue offloads API Date: Sun, 10 Sep 2017 10:48:27 -0700 Message-ID: <20170910104827.11da9230@xeon-e3> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: thomas@monjalon.net, dev@dpdk.org To: Shahaf Shuler Return-path: Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by dpdk.org (Postfix) with ESMTP id 046996841 for ; Sun, 10 Sep 2017 19:48:34 +0200 (CEST) Received: by mail-pg0-f49.google.com with SMTP id j16so1475087pga.1 for ; Sun, 10 Sep 2017 10:48:34 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, 10 Sep 2017 15:07:49 +0300 Shahaf Shuler wrote: > Introduce a new API to configure Tx offloads. > > In the new API, offloads are divided into per-port and per-queue > offloads. The PMD reports capability for each of them. > Offloads are enabled using the existing DEV_TX_OFFLOAD_* flags. > To enable per-port offload, the offload should be set on both device > configuration and queue configuration. To enable per-queue offload, the > offloads can be set only on queue configuration. > > In addition the Tx offloads will be disabled by default and be > enabled per application needs. This will much simplify PMD management of > the different offloads. > > The new API does not have an equivalent for the below, benchmark > specific, flags: > > - ETH_TXQ_FLAGS_NOREFCOUNT > - ETH_TXQ_FLAGS_NOMULTMEMP > > Applications should set the ETH_TXQ_FLAGS_IGNORE flag on txq_flags > field in order to move to the new API. > > The old Tx offloads API is kept for the meanwhile, in order to enable a > smooth transition for PMDs and application to the new API. > > Signed-off-by: Shahaf Shuler > --- Agree on a conceptual and hardware level, that this is a property that could be per queue. But is there really an application that would want to have refcounting on one queue and not another? If application is cloning mbuf's it needs refcounting. One could even argue that for safety these should be library wide. That way if an application tried to manipulate ref count on an mbuf and refcountin was enabled it could be panic'd.