[PATCH 1/7] ethdev: introduce hairpin memory capabilities

[Dariusz Sosnowski]

Hi Thomas,

> What is the benefit?

Goal of this patchset is to present application developers with more options to fine tune hairpin configuration to their use case.
I added more details regarding the possible benefits and motivation to the cover letter of v2.

> How the user knows what to use?
> Why it is not automatic in the driver?

Basic assumption is that the default behavior of the PMD (mlx5 in that specific case) is a baseline for hairpin performance.
If that default performance is enough for a user, he will not have to change anything in the hairpin queue configuration.
If performance is not satisfying, user will have to experiment with different configurations e.g., if decreasing traffic latency is a priority for the user,
user can check how his specific application works when `use_locked_device_memory` is used.

Specific performance gains of each of the hairpin options is not a given,
since hairpin performance will be a function of hairpin configuration and flow configuration (number of flows, types of flows, etc.).

> Isn't it too much low level for a user?

In my opinion, it's not too low level since purpose of these new options is fine tuning the hairpin performance to the specific use case of the application.

> > +      * - When set, PMD will use detault memory type as a backing
> > + storage. Please refer to PMD
> 
> You probably mean "clear".
> Please make lines shorter.
> You should split lines logically, after a dot or at the end of a part.

Fixed in v2.

> > +
> > +     uint32_t reserved:11; /**< Reserved bits. */
> 
> You can insert a blank line here.
> 
> >       struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
> > };

Added in v2.

Best regards,
Dariusz Sosnowski