Hi Chengchang
From: Chengchang Tang:

Hi Matan

On 2020/9/7 16:28, Matan Azrad wrote:

quoted

Hi Chengchang

From: Chengchang Tang:

quoted

Hi Matan

On 2020/9/6 21:45, Matan Azrad wrote:

quoted

Hi  Chengchang

From: Chengchang Tang:

quoted

Hi, Matan

On 2020/9/2 18:30, Matan Azrad wrote:

quoted

Hi Chengchang

From: Chengchang Tang

quoted

Hi, Matan

On 2020/9/2 15:19, Matan Azrad wrote:

quoted

Hi Chengchang

From: Chengchang Tang

quoted

Hi, Matan

On 2020/9/1 23:33, Matan Azrad wrote:

quoted

Hi Chengchang

Please see some question below.

From: Chengchang Tang

quoted

Add a field named rx_buf_size in rte_eth_rxq_info to indicate
the buffer size used in receiving packets for HW.

In this way, upper-layer users can get this information by
calling rte_eth_rx_queue_info_get.

Signed-off-by: Chengchang Tang

[off-list ref]

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Reviewed-by: Wei Hu (Xavier) <redacted>
Acked-by: Andrew Rybchenko <redacted>
---
 lib/librte_ethdev/rte_ethdev.h | 2 ++
 1 file changed, 2 insertions(+)

<snip>

quoted

quoted

quoted

quoted

So the user can configure X and the driver will use Y!=X?

Yes, it depends on the HW. In the queue setup API, it just checks
whether the input is greater than the required minimum value. But
HW usually has requirements for alignment and so on.
So when X does not meet these requirements, PMDs will calculate a
new value Y that meets these requirements to configure the hardware
(Y <= X, to ensure no memory overflow occurs).

quoted

Should the application validate its own configurations after
setting them

successfully?

It depends on their own needs. The application should not be forced
to verify it to avoid affecting the ease of use of PMDs. For some
applications, they don't care about this value.

I understand,
It looks me like a bad ping-pong between app and PMD (for all the
fields in the struct), And we should avoid adding fields to this
structure if

we can.

quoted

What's about adding field in rte_eth_dev_info to expose the rx
buffer

alignment supported by the PMD?

quoted

Then, application has all the knowledge you want to expose before
the

configuration.

This may not work because there may be other restrictions besides
alignment, which are related to the hardware design. Therefore, it is
difficult to describe all constraints in a single field.
Moreover, this approach seems to
constrain the PMDs and HW to some extent.

Ok, so maybe other ethdev capability API to get the Rx buffer size

adjustment by the PMD?

quoted

Don't you think it is important information to the application in order to

decide the mempool buffer size \ enabling scatter?

I guess what you mean is that it's more like a capability, so the application
should query it through a capability API.

Yes.

If i understand correctly, I agree with that. But I think it's okay to use this
structure to export queue related information at runtime. It focuses on
querying the current queue configuration.

Why do we need it If the capability(suggested above) say it already? 

And there seems to be no suitable API for querying this capability. Maybe we
need to introduce a new API to do this. But I'm not sure if it's really
necessary.

 
For example if the user use room of size X in the RX mempool and the PMD configures X/2 because of HW limitation:
Don't you think it will affect the user configuration of mempool and scatter mode?

quoted

In any case, I think you should add documentation in the RX setup API that

the HW buf size may be changed by the PMD.

There is not a defined rule of how to configure Rx buffer size. That is, there is
no specific method to configure the Rx buffer size for applications. However,
most PMDs configure the Rx buffer size base on the data size of the
mempool. So, if the description is added to the setup API, the method for
configuring the Rx buffer size is determined. I think this issue should involve
more people in the discussion, maybe we should send a separate patch.

The mempool parameter of RX say it exactly, no?

quoted

<snip>

.