> >> On 7/21/2019 3:24 PM, Viacheslav Ovsiienko wrote: > >>> Mellanox NICs support the wide set of Tx offloads. The supported > >>> offloads are reported by the mlx5 PMD in rte_eth_dev_info > >>> tx_offload_capa field. An application may choose any combination of > >>> supported offloads and configure the device appropriately. Some of > >>> Tx offloads may be not requested by application, or ever all of them > >>> may be > >> omitted. > >>> Most of the Tx offloads require some code branches in tx_burst > >>> routine to support ones. If Tx offload is not requested the tx_burst > >>> routine code may be significantly simplified and consume less CPU > cycles. > >>> > >>> For example, if application does not engage TSO offload this code > >>> can be omitted, if multi-segment packet is not supposed the tx_burst > >>> may assume single mbuf packets only, etc. > >>> > >>> Currently, the mlx5 PMD implements multiple tx_burst subroutines for > >>> most common combinations of requested Tx offloads, each branch has > >>> its own dedicated implementation. It is not very easy to update, > >>> support and develop such kind of code - multiple branches impose the > >>> multiple points to process. Also many of frequently requested > >>> offload combinations are not supported yet. That leads to selecting > >>> of not completely matching tx_burst routine and harms the > performance. > >>> > >>> This patch introduces the new approach for tx_burst code. It is > >>> proposed to develop the unified template for tx_burst routine, which > >>> supports all the Tx offloads and takes the compile time defined > >>> parameter describing the supposed set of supported offloads. On the > >>> base of this template, the compiler is able to generate multiple > >>> tx_burst routines highly optimized for the statically specified set > >>> of Tx > >> offloads. > >>> Next, in runtime, at Tx queue configuration the best matching > >>> optimized implementation of tx_burst is chosen. > >>> > >>> This patch intentionally omits the template internal implementation, > >>> but just introduces the template itself to emboss the approach of > >>> the multiple specially tuned tx_burst routines. > >>> > >>> Signed-off-by: Viacheslav Ovsiienko <viachesl...@mellanox.com> > >> > >> Getting following build error with icc, can you please check? > >> > >> > >> .../dpdk/drivers/net/mlx5/mlx5_rxtx.c(4649): error #191: type > >> qualifier is meaningless on cast type > >> > >> > >> MLX5_TXOFF_DECL(full_empw, > >> > > Sorry, I have no icc at my disposal now. What I can say (sorry again, > > it is obvious) > > - It definitely does not like the MLX5_TXOFF_DECL macro. Most likely - > "restrict" qualifier, I think. > > > > With best regards, Slava > > > > Hi Slava, > > I was hoping error log can give enough hint, but I tested by removing the > 'restrict' keyword and it fixed the icc warning. > > Can you please check if the 'icc' is right and 'restrict' is meaningless, if > so can > you please send a patch to remove it? > else please let me know and I can make a patch to disable the specific icc > warning.
Hi, it is difficult to say whether qualifier is meaningless, at least I was unable to find the proof in C99 std - neither in type cast nor in qualifiers chapters. From common sense the routine expects the qualified type, we should provide. Anyway, I've checked gcc/clang compilation with dropped restrict qualifier and it was OK. Optimization was not harmed as well. With best regards, Slava
