From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
 by dpdk.org (Postfix) with ESMTP id 5B98A5594
 for <dev@dpdk.org>; Wed, 27 Jul 2016 10:59:02 +0200 (CEST)
Received: by mail-wm0-f43.google.com with SMTP id q128so29723772wma.1
 for <dev@dpdk.org>; Wed, 27 Jul 2016 01:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=date:from:to:cc:subject:message-id:user-agent:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=Xgk/uxyPokSZfp6qIrXkuiQGm09YxGWVinCCbFW5//o=;
 b=aS9QzgwluOvZYQiPuECgpWG1YBdB5EiVZpsC9tME30jGEpDV62dLhGb7LWWVoCNzko
 gRsTeiXyIMHfXqVgpunOIixTKm+or94lZSm2vCkQQwRo9oCQm6XyxMHUv4YwiKqivf1n
 iTYb0SswsfTMX3NoYXzg7pmR3Kb1JXBNXgJeTLPtLAHz609QUG8SkPy8lmhHQacT2WxP
 IBKAtqoLDzYvvURsKqdWgKvgdEwA6QzNwlQO/aEzSyjWsRK/Z33BLyRkRyKEGTEr+huC
 Sbz1PWmMRKL4etG/WAHFCh8SGkjeF6KyFpww2U7pf8Z5XFE5pENo0mTWljiNWWsTos7v
 2V7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=Xgk/uxyPokSZfp6qIrXkuiQGm09YxGWVinCCbFW5//o=;
 b=V/SpSRuG82qIZB314OVAPH72PNABalJFSmFKWxO0IOEj4Grfjdag2156dzIiqwFlbN
 c74bu/V6kQlzjRoCBd1yhWJBjW23TanEGbXrO2ly3Ikdggdb8hFp6WdQ10RJ+c5aesEv
 eNRf0wB/GWCism1TsyWjxVl3gdBArYRxZhyVlEmbKOIgxVpIgzZYYOUnd8RPuWUK7e27
 a71rzj/uyXRjcU12UVlG/0NqJ+rQfjzaPIBzy5k1pNNUgSX5A1XrnMi2Bje5U+4L0Ehh
 ziotZnfGZpF76QwS1h0wsb1qhGgXJoe6b2bpgZ40sGGz/6vPHko6MUy/s3GVWfCwh0By
 lALA==
X-Gm-Message-State: ALyK8tLdc2GoR4Lcyw+abS8V6pCHSpIwzEnqlizlGWtAH2DxyoUFBvnyqnmjVqoFzmiCTT7x
X-Received: by 10.28.150.146 with SMTP id y140mr34302125wmd.32.1469609942106; 
 Wed, 27 Jul 2016 01:59:02 -0700 (PDT)
Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184])
 by smtp.gmail.com with ESMTPSA id 3sm6030372wms.1.2016.07.27.01.59.00
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 27 Jul 2016 01:59:01 -0700 (PDT)
Date: Wed, 27 Jul 2016 01:59:01 -0700 (PDT)
X-Google-Original-Date: Wed, 27 Jul 2016 10:59 +0200
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>
Cc: dev@dpdk.org, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Message-ID: <2146153.nVzdynOqdk@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com>
References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com>
 <1469114659-66063-1-git-send-email-tomaszx.kulasek@intel.com>
 <2601191342CEEE43887BDE71AB97725836B80AD8@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 v2] doc: announce ABI change for
	rte_eth_dev	structure
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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: Wed, 27 Jul 2016 08:59:02 -0000

> > Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
> > ---
> > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure will be
> > +  extended with new function pointer ``tx_pkt_prep`` allowing verification
> > +  and processing of packet burst to meet HW specific requirements before
> > +  transmit. Also new fields will be added to the ``rte_eth_desc_lim`` structure:
> > +  ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information about number of
> > +  segments limit to be transmitted by device for TSO/non-TSO packets.
> 
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

I think I understand you want to split the TX processing:
	1/ modify/write in mbufs
	2/ write in HW
and let application decide:
	- where the TX prep is done (which core)
	- what to do if the TX prep fail
So adding some processing in this first part becomes "not too expensive" or
"manageable" from the application point of view.

If I well understand the intent,

Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
(except typos ;)