Hi All,
This patch set introduces some important data path RX refactoring
addressing mlx5e memory allocation/management improvements and XDP support.
Submitting as RFC since we would like to get an early feedback, while we
continue reviewing testing and complete the performance analysis in house.
In details:
>From Tariq, three patches that address the page allocation and memory
>fragmentation
issue of mlx5e striding RQ, where we used to allocate order 5 pages then split
them
into order 0 pages. Basically we now allocate only order 0 pages and we default
to what we used to call the fallback mechanism (ConnectX4 UMR) to virtually map
them into device as one big chunk. The last two patches in his series, Tariq
introduces
a mapped pages internal cache API for mlx5e driver to recover from the
performance
degradation we hit, since now we allocate 32 order 0 pages when required in
striding RQ
RX path. Those two patches of mapped pages cache API are needed later in my
series
of XDP support.
XDP support:
To have proper XDP support a "page per packet" is a must have prerequisite and
neither of our two RX modes can trivially do XDP. Striding RQ is not an option,
since the whole idea from it is to share memory and have minimum HW descriptors
for as much packets as we can.
The other mode is a regular RX ring mode where we have a HW descriptor per
packet,
but the main issue is that ring SKBs are allocated in advance and skb->data is
mapped
directly to device (drop decision will not be as fast as we want, since we will
need to
free the skb). For that we've made some RX refactoring also in regular RQ mode
area
where we now allocate a page per packet and use build_skb. To overcome the
page allocator
overhead, we use the page cache API. For those who have ConnectX4-LX where
striding RQ is
the default, if xdp is requested we will move to regular ring RQ mode, and move
back to
striding mode when xdp goes back to off.
Some issues are needed to be addressed now, having a page per packet is not
perfect as
it seems, driver memory consumption just got up, and as a future work, we need
to
share pages for multiple packets when XDP is off, especially for systems with
large
PAGE_SIZE.
For XDP TX forwarding support, we add it in the last two patches.
Nothing is really special there :).
You will find much more details and initial performance numbers in the patches
commit messages.
Thanks,
Saeed.
Rana Shahout (1):
net/mlx5e: XDP fast RX drop bpf programs support
Saeed Mahameed (7):
net/mlx5e: Build RX SKB on demand
net/mlx5e: Union RQ RX info per RQ type
net/mlx5e: Slightly reduce hardware LRO size
net/mlx5e: Dynamic RQ type infrastructure
net/mlx5e: Have a clear separation between different SQ types
net/mlx5e: XDP TX forwarding support
net/mlx5e: XDP TX xmit more
Tariq Toukan (3):
net/mlx5e: Single flow order-0 pages for Striding RQ
net/mlx5e: Introduce API for RX mapped pages
net/mlx5e: Implement RX mapped page cache for page recycle
drivers/net/ethernet/mellanox/mlx5/core/en.h | 144 +++--
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 581 +++
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c| 618 ++---
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 32 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c| 61 +-
drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 67 ++-
6 files changed, 998 insertions(+), 505 deletions(-)
--
2.7.4