Re: [PATCH bpf-next v5 00/16] AF_XDP infrastructure improvements and mlx5e support

[Tariq Toukan <tariqt@mellanox.com>]

On 6/21/2019 10:52 PM, Saeed Mahameed wrote:
> On Thu, Jun 20, 2019 at 2:13 AM Björn Töpel <bjorn.topel@gmail.com> wrote:
>>
>> On Tue, 18 Jun 2019 at 14:00, Maxim Mikityanskiy <maximmi@mellanox.com> wrote:
>>>
>>> This series contains improvements to the AF_XDP kernel infrastructure
>>> and AF_XDP support in mlx5e. The infrastructure improvements are
>>> required for mlx5e, but also some of them benefit to all drivers, and
>>> some can be useful for other drivers that want to implement AF_XDP.
>>>
>>> The performance testing was performed on a machine with the following
>>> configuration:
>>>
>>> - 24 cores of Intel Xeon E5-2620 v3 @ 2.40 GHz
>>> - Mellanox ConnectX-5 Ex with 100 Gbit/s link
>>>
>>> The results with retpoline disabled, single stream:
>>>
>>> txonly: 33.3 Mpps (21.5 Mpps with queue and app pinned to the same CPU)
>>> rxdrop: 12.2 Mpps
>>> l2fwd: 9.4 Mpps
>>>
>>> The results with retpoline enabled, single stream:
>>>
>>> txonly: 21.3 Mpps (14.1 Mpps with queue and app pinned to the same CPU)
>>> rxdrop: 9.9 Mpps
>>> l2fwd: 6.8 Mpps
>>>
>>> v2 changes:
>>>
>>> Added patches for mlx5e and addressed the comments for v1. Rebased for
>>> bpf-next.
>>>
>>> v3 changes:
>>>
>>> Rebased for the newer bpf-next, resolved conflicts in libbpf. Addressed
>>> Björn's comments for coding style. Fixed a bug in error handling flow in
>>> mlx5e_open_xsk.
>>>
>>> v4 changes:
>>>
>>> UAPI is not changed, XSK RX queues are exposed to the kernel. The lower
>>> half of the available amount of RX queues are regular queues, and the
>>> upper half are XSK RX queues. The patch "xsk: Extend channels to support
>>> combined XSK/non-XSK traffic" was dropped. The final patch was reworked
>>> accordingly.
>>>
>>> Added "net/mlx5e: Attach/detach XDP program safely", as the changes
>>> introduced in the XSK patch base on the stuff from this one.
>>>
>>> Added "libbpf: Support drivers with non-combined channels", which aligns
>>> the condition in libbpf with the condition in the kernel.
>>>
>>> Rebased over the newer bpf-next.
>>>
>>> v5 changes:
>>>
>>> In v4, ethtool reports the number of channels as 'combined' and the
>>> number of XSK RX queues as 'rx' for mlx5e. It was changed, so that 'rx'
>>> is 0, and 'combined' reports the double amount of channels if there is
>>> an active UMEM - to make libbpf happy.
>>>
>>> The patch for libbpf was dropped. Although it's still useful and fixes
>>> things, it raises some disagreement, so I'm dropping it - it's no longer
>>> useful for mlx5e anymore after the change above.
>>>
>>
>> Just a heads-up: There are some checkpatch warnings (>80 chars/line)
> 
> Thanks Bjorn for your comment, in mlx5 we allow up to 95 chars per line,
> otherwise it is going to be an ugly zigzags.
> 
>> for the mlnx5 driver parts, and the series didn't apply cleanly on
>> bpf-next for me.
>>
>> I haven't been able to test the mlnx5 parts.
>>
>> Parts of the series are unrelated/orthogonal, and could be submitted
>> as separate series, e.g. patches {1,7} and patches {3,4}. No blockers
>> for me, though.
>>
>> Thanks for the hard work!
>>
>> For the series:
>> Acked-by: Björn Töpel <bjorn.topel@intel.com>

Just wanted to make sure we're on the same page, so we don't miss this 
kernel.

AIU, currently no action is needed from Maxim's side, as Saeed is fine 
with the mlx5 part, and series is still marked as 'New' in patchworks 
with no requested changes.

Regards,
Tariq