DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api
Date: Tue, 08 Mar 2016 23:52:05 +0100	[thread overview]
Message-ID: <4446137.g0qt5Fe5Df@xps13> (raw)
In-Reply-To: <1456333729-3804-2-git-send-email-tomaszx.kulasek@intel.com>

Hi,

It is an overlay on the tx burst API.
Probably it doesn't hurt to add it but we have to be really cautious
with the API definition to try keeping it stable in the future.

2016-02-24 18:08, Tomasz Kulasek:
> +/**
> + * Structure used to buffer packets for future TX
> + * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush
> + */
> +struct rte_eth_dev_tx_buffer {
> +	unsigned nb_pkts;

What about "length"?
Why is it unsigned and the size is uint16_t?

> +	uint64_t errors;
> +	/**< Total number of queue packets to sent that are dropped. */

The errors are passed as userdata to the default callback.
If we really want to have this kind of counter, we can define our
own callback. So why defining this field as standard?
I would like to keep it as simple as possible.

> +	buffer_tx_error_fn cbfn;

Why not simply "callback" as name?

> +	void *userdata;
> +	uint16_t size;           /**< Size of buffer for buffered tx */
> +	struct rte_mbuf *pkts[];
> +};

What is the benefit of exposing this structure in the API,
except that it is used in some inline functions?

> +static inline uint16_t
> +rte_eth_tx_buffer_flush(uint8_t port_id, uint16_t queue_id,
> +		struct rte_eth_dev_tx_buffer *buffer)
> +{
> +	uint16_t sent;
> +
> +	uint16_t to_send = buffer->nb_pkts;
> +
> +	if (to_send == 0)
> +		return 0;

Why this check is done in the lib?
What is the performance gain if we are idle?
It can be done outside if needed.

> +	sent = rte_eth_tx_burst(port_id, queue_id, buffer->pkts, to_send);
> +
> +	buffer->nb_pkts = 0;
> +
> +	/* All packets sent, or to be dealt with by callback below */
> +	if (unlikely(sent != to_send))
> +		buffer->cbfn(&buffer->pkts[sent], to_send - sent,
> +				buffer->userdata);
> +
> +	return sent;
> +}
[...]
> +/**
> + * Callback function for tracking unsent buffered packets.
> + *
> + * This function can be passed to rte_eth_tx_buffer_set_err_callback() to
> + * adjust the default behaviour when buffered packets cannot be sent. This
> + * function drops any unsent packets, but also updates a user-supplied counter
> + * to track the overall number of packets dropped. The counter should be an
> + * uint64_t variable.
> + *
> + * NOTE: this function should not be called directly, instead it should be used
> + *       as a callback for packet buffering.
> + *
> + * NOTE: when configuring this function as a callback with
> + *       rte_eth_tx_buffer_set_err_callback(), the final, userdata parameter
> + *       should point to an uint64_t value.

Please forget this idea of counter in the default callback.

[...]
> +void
> +rte_eth_count_unsent_packet_callback(struct rte_mbuf **pkts, uint16_t unsent,
> +		void *userdata);

What about rte_eth_tx_buffer_default_callback as name?

  reply	other threads:[~2016-03-08 22:53 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15 14:43 [dpdk-dev] [PATCH 0/2] add support for buffered tx to ethdev Tomasz Kulasek
2016-01-15 14:43 ` [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-01-15 18:13   ` Stephen Hemminger
2016-01-15 18:14   ` Stephen Hemminger
2016-01-15 18:44   ` Ananyev, Konstantin
2016-02-02 10:00     ` Kulasek, TomaszX
2016-02-02 13:49       ` Ananyev, Konstantin
2016-02-09 17:02         ` Kulasek, TomaszX
2016-02-09 23:56           ` Ananyev, Konstantin
2016-02-12 11:44             ` Ananyev, Konstantin
2016-02-12 16:40               ` Ivan Boule
2016-02-12 17:33                 ` Bruce Richardson
2016-01-15 14:43 ` [dpdk-dev] [PATCH 2/2] examples: sample apps rework to use " Tomasz Kulasek
2016-01-15 18:12 ` [dpdk-dev] [PATCH 0/2] add support for buffered tx to ethdev Stephen Hemminger
2016-02-24 17:08 ` [dpdk-dev] [PATCH v2 " Tomasz Kulasek
2016-02-24 17:08   ` [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-08 22:52     ` Thomas Monjalon [this message]
2016-03-09 13:36       ` Ananyev, Konstantin
2016-03-09 14:25         ` Thomas Monjalon
2016-03-09 15:23           ` Ananyev, Konstantin
2016-03-09 15:26             ` Thomas Monjalon
2016-03-09 15:32               ` Kulasek, TomaszX
2016-03-09 15:37                 ` Thomas Monjalon
2016-03-09 15:42               ` Ananyev, Konstantin
2016-03-09 15:52                 ` Thomas Monjalon
2016-03-09 16:17                   ` Ananyev, Konstantin
2016-03-09 16:21                     ` Thomas Monjalon
2016-03-09 16:35       ` Kulasek, TomaszX
2016-03-09 17:06         ` Thomas Monjalon
2016-03-09 18:12           ` Kulasek, TomaszX
2016-02-24 17:08   ` [dpdk-dev] [PATCH v2 2/2] examples: rework to use " Tomasz Kulasek
2016-02-25 16:17   ` [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 10:57   ` [dpdk-dev] [PATCH v3 " Tomasz Kulasek
2016-03-10 10:57     ` [dpdk-dev] [PATCH v3 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 16:23       ` Thomas Monjalon
2016-03-10 17:15         ` Kulasek, TomaszX
2016-03-10 10:57     ` [dpdk-dev] [PATCH v3 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-10 11:31     ` [dpdk-dev] [PATCH v3 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 16:01       ` Jastrzebski, MichalX K
2016-03-10 17:19     ` [dpdk-dev] [PATCH v4 " Tomasz Kulasek
2016-03-10 17:19       ` [dpdk-dev] [PATCH v4 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 17:19       ` [dpdk-dev] [PATCH v4 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-11 16:39       ` [dpdk-dev] [PATCH v4 0/2] add support for buffered tx to ethdev Thomas Monjalon

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=4446137.g0qt5Fe5Df@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=dev@dpdk.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).