diff mbox series

eal: added new api to only enqueue a packet in tx buffer

Message ID 20190808122819.6015-1-nsarkar@sandvine.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers
Series eal: added new api to only enqueue a packet in tx buffer |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/iol-Compile-Testing success Compile Testing PASS
ci/intel-Performance-Testing success Performance Testing PASS
ci/mellanox-Performance-Testing success Performance Testing PASS

Commit Message

Nilanjan Sarkar Aug. 8, 2019, 12:28 p.m. UTC 
  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.

Signed-off-by: Nilanjan Sarkar <nsarkar@sandvine.com>
---
 lib/librte_ethdev/rte_ethdev.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

Comments

Ferruh Yigit Oct. 18, 2019, 4:24 p.m. UTC | #1 
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
>
Ferruh Yigit Nov. 11, 2019, 4:56 p.m. UTC | #2 
On 10/18/2019 5:24 PM, Yigit, Ferruh wrote:
> 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?
> 

There was no response on making the new proposed API a proper function.

@Thomas, @Andrew, et al,

What do you think about a new static inline ethdev API?

> 
>>
>> 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
>>
>
Thomas Monjalon Nov. 11, 2019, 5:30 p.m. UTC | #3 
11/11/2019 17:56, Ferruh Yigit:
> On 10/18/2019 5:24 PM, Yigit, Ferruh wrote:
> > 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?
> > 
> 
> There was no response on making the new proposed API a proper function.
> 
> @Thomas, @Andrew, et al,
> 
> What do you think about a new static inline ethdev API?
> 
> >> +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;
> >> +}

It looks reasonnable.
But the function name should include _buffer_
What about rte_eth_tx_buffer_enqueue?
Andrew Rybchenko Nov. 12, 2019, 7:17 a.m. UTC | #4 
On 11/11/19 8:30 PM, Thomas Monjalon wrote:
> 11/11/2019 17:56, Ferruh Yigit:
>> On 10/18/2019 5:24 PM, Yigit, Ferruh wrote:
>>> 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?
>>>
>>
>> There was no response on making the new proposed API a proper function.
>>
>> @Thomas, @Andrew, et al,
>>
>> What do you think about a new static inline ethdev API?
>>
>>>> +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;
>>>> +}
> 
> It looks reasonnable.
> But the function name should include _buffer_
> What about rte_eth_tx_buffer_enqueue?

+1
diff mbox series

Patch

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