All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>
Cc: dev@dpdk.org, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [PATCH v2] doc: announce ABI change for rte_eth_dev	structure
Date: Wed, 27 Jul 2016 01:59:01 -0700 (PDT)	[thread overview]
Message-ID: <2146153.nVzdynOqdk@xps13> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com>

> > 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 ;)

  reply	other threads:[~2016-07-27  8:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20 14:24 [PATCH] doc: announce ABI change for rte_eth_dev structure Tomasz Kulasek
2016-07-20 15:01 ` Thomas Monjalon
2016-07-20 15:13   ` Ananyev, Konstantin
2016-07-20 15:22     ` Thomas Monjalon
2016-07-20 15:42       ` Kulasek, TomaszX
2016-07-21 15:24 ` [PATCH v2] " Tomasz Kulasek
2016-07-21 22:48   ` Ananyev, Konstantin
2016-07-27  8:59     ` Thomas Monjalon [this message]
2016-07-27 17:10       ` Jerin Jacob
2016-07-27 17:33         ` Ananyev, Konstantin
2016-07-27 17:41           ` Jerin Jacob
2016-07-27 20:51             ` Ananyev, Konstantin
2016-07-28  2:13               ` Jerin Jacob
2016-07-28 10:36                 ` Ananyev, Konstantin
2016-07-28 11:38                   ` Jerin Jacob
2016-07-28 12:07                     ` Avi Kivity
2016-07-28 13:01                     ` Ananyev, Konstantin
2016-07-28 13:58                       ` Olivier MATZ
2016-07-28 14:21                         ` Ananyev, Konstantin
2016-07-28 13:59                       ` Jerin Jacob
2016-07-28 14:52                         ` Thomas Monjalon
2016-07-28 16:25                           ` Jerin Jacob
2016-07-28 17:07                             ` Thomas Monjalon
2016-07-31  7:50     ` Vlad Zolotarov
2016-07-28 12:04   ` Avi Kivity
2016-07-31  7:46 ` [PATCH] " Vlad Zolotarov
2016-07-31  8:10   ` Vlad Zolotarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2146153.nVzdynOqdk@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=tomaszx.kulasek@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.