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
