DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Yigit, Ferruh" <ferruh.yigit@linux.intel.com>
To: Nilanjan Sarkar <nsarkar@sandvine.com>, dev@dpdk.org
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	Olivier MATZ <olivier.matz@6wind.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [dpdk-dev] [PATCH] eal: added new api to only enqueue a packet in tx buffer
Date: Fri, 18 Oct 2019 17:24:44 +0100	[thread overview]
Message-ID: <e137096d-eae7-9c5a-d6fd-6d5b78d5cbdc@linux.intel.com> (raw)
In-Reply-To: <20190808122819.6015-1-nsarkar@sandvine.com>

On 8/8/2019 1:28 PM, Nilanjan Sarkar wrote:
> This api is similar like api `rte_eth_tx_buffer` except it
> does not attempt to flush the buffer in case buffer is full.
> The advantage is that, this api does not need port id and
> queue id. In case port id and queue id are shared within threads
> then application can not buffer a packet until it gets access
> to port and queue. So this function segregate buffering
> job from flushing job and thus removes dependency on port and queue.

Hi Nilanjan,

Sorry, the patch seems missed because of the misleading module info in the patch
title, this is not an 'eal' patch but a 'ethdev' patch ...

Related to the API, it looks like target is to reduce the critical section which
looks reasonable to me.

A concern is related to the making this function inline, we are discussing
moving existing inline functions to regular functions, this may have performance
affect but if the drop is acceptable what about making this an ethdev API?

Thanks,
ferruh

> 
> Signed-off-by: Nilanjan Sarkar <nsarkar@sandvine.com>
> ---
>  lib/librte_ethdev/rte_ethdev.h | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index dc6596bc9..bd8b8fee4 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -4569,6 +4569,35 @@ rte_eth_tx_buffer(uint16_t port_id, uint16_t queue_id,
>  	return rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
>  }
>  
> +/**
> + * Buffer a single packet for future transmission on Tx buffer. This buffer
> + * can be sent to a port and queue of a NIC using rte_eth_tx_buffer_flush ()
> + * call.
> + *
> + * This function enqueues a packet to Tx buffer. In case there is no space
> + * in Tx buffer, this function fails.
> + * Tx buffer will be flushed using rte_eth_tx_buffer_flush () call. It is
> + * application's responsibility to flush the Tx buffer in regular interval.
> + *
> + * @param buffer
> + *  Buffer used to collect packets to be sent.
> + * @param tx_pkt
> + *  Pointer to the packet mbuf to be sent.
> + * @return
> + *  0 = packet has been buffered for later transmission
> + *  -1 = Packet can not be buffered since it reached limit
> + */
> +static __rte_always_inline int
> +rte_eth_tx_enqueue(struct rte_eth_dev_tx_buffer *buffer, struct rte_mbuf *tx_pkt)
> +{
> +	if (buffer->length < buffer->size) {
> +		buffer->pkts[buffer->length++] = tx_pkt;
> +		return 0;
> +	}
> +
> +	return -1;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 


  reply	other threads:[~2019-10-18 16:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 12:28 Nilanjan Sarkar
2019-10-18 16:24 ` Yigit, Ferruh [this message]
2019-11-11 16:56   ` Ferruh Yigit
2019-11-11 17:30     ` Thomas Monjalon
2019-11-12  7:17       ` Andrew Rybchenko
  -- strict thread matches above, loose matches on Subject: below --
2019-08-21  5:59 Nilanjan Sarkar
2019-08-08 11:53 Nilanjan Sarkar
2019-08-08 11:17 Nilanjan Sarkar

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=e137096d-eae7-9c5a-d6fd-6d5b78d5cbdc@linux.intel.com \
    --to=ferruh.yigit@linux.intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=nsarkar@sandvine.com \
    --cc=olivier.matz@6wind.com \
    --cc=ray.kinsella@intel.com \
    --cc=thomas@monjalon.net \
    /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).