[bug] i40e 2.26.8 XDP_REDIRECT is not available with Linux 6.5

[hiyouthinker]

When bpf_redirect_map is used for redirection in the XDP, the backend does not receive the packet.
After analysis, it is found that dev->xdp_features does not set the NETDEV_XDP_ACT_NDO_XMIT flag, causing the packet to be discarded.
And NETDEV_XDP_ACT_NDO_XMIT is set by calling xdp_features_set_redirect_target when binding XDP program to dev device. HAVE_AF_XDP_ZC_SUPPORT is not defined when compiling on the Linux 6.5 platform, resulting in xdp_features_set_redirect_target not being called.
In fact, there is no relationship between the two.
Therefore, xdp_features_set_redirect_target is placed outside indef HAVE_AF_XDP_ZC_SUPPORT.

Signed-off-by: Qingzhi Yang [email protected]

[imcom]

hi @aloktion @rdower would you please assign this PR to someone for review. This is a blocking issue on our platform. We need to run XDP with Linux kernel 6.5 and i40e driver. Thanks!

[aloktion]

Good day @Kubiak, ***@***.***> Can you find someone from XDP team to review? Thank you Alex From: imcom ***@***.***> Sent: Thursday, September 26, 2024 4:07 AM To: intel/ethernet-linux-i40e ***@***.***> Cc: Loktionov, Aleksandr ***@***.***>; Mention ***@***.***> Subject: Re: [intel/ethernet-linux-i40e] [bug] i40e 2.26.8 XDP_REDIRECT is not available with Linux 6.5 (PR #7) hi @aloktion<https://github.com/aloktion> @rdower<https://github.com/rdower> would you please assign this PR to someone for review. This is a blocking issue on our platform. We need to run XDP with Linux kernel 6.5 and i40e driver. Thanks! — Reply to this email directly, view it on GitHub<#7 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATTGNVYQPF6D6F6IQMGWVE3ZYNT45AVCNFSM6AAAAABO247MJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZVGYYDKOJWGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JonKohler]

hey @aloktion - can you help clarify Intel's position on open source contributions to both i40e and as well as the other github/intel/ethernet-linux* repositories?

It looks like from the commit log into this repo that this is not the canonical repo for this driver (or all of the other drivers), but rather a mirror of an Intel internal source control.

That's fine, but it would be good for the community to understand if issues and pull requests are going to be handled on the repository, or not.

[aloktion]

Good day Jon

I'm TL of igb, ixgbe, ixgbevf and i40e linux base drivers, for acceleration technologies for example XDP, RDMA there are different teams.
This repo is the public place for Intel open source linux base driver releases.
For information about support please read the readme of the specific driver.

[JonKohler]

Great, thank you for responding quickly. To clarify, does that mean Intel will be accepting GitHub PRs and GitHub issues? or should that be driven exclusively by Intel alone? Thats fine if that's the case, I just want to make sure the expectation is clear.

I see the readme says (below) see the project hosted on GitHub, but I'm assuming what the last paragraph means is that support should go through an Intel IPS ticket instead?

Support
=======

For general information, go to the Intel support website at
https://www.intel.com/support/

or the Intel Ethernet Linux project hosted by GitHub at
https://github.com/intel/ethernet-linux-i40e

If an issue is identified with the released source code on a supported
kernel with a supported adapter, contact Intel Customer Support at
https://www.intel.com/content/www/us/en/support/products/36773
/ethernet-products.html```

[aloktion]

Please use IPS

[JonKohler]

Please use IPS

Ok, if that is the case, I think it would reduce confusion going forward if at least GitHub pull requests were shut off at a repo level for all of Intel's ethernet repos, as otherwise it leaves open for confusion that Intel will accept pull requests.

Having GitHub issues open would probably still be nice though, as that would allow the community to at least point out issues, where community members may not have access to IPS.

[michalQb]

The solution is correct. The call of xdp_features_set_redirect_target() is independent on zero-copy support.
Please also move the comment Kick start the NAPI context... before the for loop because the comment is also specific just to the AF_XDP_ZC.

#ifdef HAVE_AF_XDP_ZC_SUPPORT
		/* Kick start the NAPI context if there is an AF_XDP socket open
		 * on that queue id. This so that receiving will start.
		 */
		for (i = 0; i < vsi->num_queue_pairs; i++)

Please re-format the commit message to preserve the kernel standards for line lenght.
Also, I would say that the following statement is not entirely true:
HAVE_AF_XDP_ZC_SUPPORT is not defined when compiling on the Linux 6.5 platform
because according to our kcompat we support AF_XDP_ZC for all mainline kernels from their 4.20.0 version. As far as I know, the support for XDP sockets may be disabled using the kernel config variable, so maybe this is your case for 6.5?
So, I would suggest to edit that sentence to be more precise.

Anyway, as I stated on the beginning, I agree that xdp_features_set_redirect_target() should not be dependent on AF_XDP_ZC support.

Thanks,
Michal

[imcom]

Suggested change

	/* Kick start the NAPI context if there is an AF_XDP socket open
	* on that queue id. This so that receiving will start.
	*/
	if (need_reset && prog) {
	#ifdef HAVE_AF_XDP_ZC_SUPPORT
	for (i = 0; i < vsi->num_queue_pairs; i++)
	if (need_reset && prog) {
	#ifdef HAVE_AF_XDP_ZC_SUPPORT
	/* Kick start the NAPI context if there is an AF_XDP socket open
	* on that queue id. This so that receiving will start.
	*/
	for (i = 0; i < vsi->num_queue_pairs; i++)