10/11/2026 13:52, Frank Dressler: > On 11/10/26 10:39, Thomas Monjalon wrote: > > 09/11/2026 18:47, Stephen Hemminger: > >> On Mon, 9 Nov 2026 17:47:30 +0200 > >> Bing Zhao <[email protected]> wrote: > >> > >>> The PACKET_IGNORE_OUTGOING socket option is used unconditionally, > >>> but it was only added to the uapi headers in Linux 4.20. The build > >>> fails on distributions shipping older kernel headers, like RHEL 8 > >>> (kernel-headers 4.18.0): > >>> > >>> rte_eth_af_packet.c:1057:41: error: 'PACKET_IGNORE_OUTGOING' > >>> undeclared (first use in this function) > >>> > >>> DPDK requires Linux 5.4, so the driver does not need to support older > >>> kernels. Check for the symbol at configure time and skip the driver > >>> when the headers lack it, instead of failing the whole build. > >>> > >>> Fixes: 3db7aa7868b2 ("net/af_packet: use kernel to filter single-queue > >>> Rx") > >>> > >>> Signed-off-by: Bing Zhao <[email protected]> > >>> --- > >> > >> No. DPDK should just fail build on older kernels. > >> Since current DPDK is not tested with those releases, anyone doing that is > >> working outside the tested environment and has to fix it themselves. > > > > We used to support some old RHEL versions. > > Remind that the RHEL kernel is full of backports, > > it is not exactly the same as an really old kernel. > > I think this solution disabling a driver is acceptable. > > But does RHEL itself actually have a problem? I could not find an > incompatible DPDK being shipped by them. DOCA ships unsupported DPDK. > > If it is RHEL, Redhat could add `-Ddisable_drivers=net/af_packet`. If it > is DOCA, NVIDIA could just add `-Ddisable_drivers=net/af_packet`. DOCA > already only ships a limited set of PMDs in their bundled DPDK.
I don't know why you insist on DOCA, it is not an upstream concern, and was not mentioned in this thread except by you. > Or is this change more intended for third-parties cloning and building > DPDK 26.11 on RHEL 8? Yes my concern is to allow building a new DPDK easily. But I am still waiting for a confirmation from our Red Hat friend that RHEL 8 is still a target. > If RHEL 8 must be supported, the documented requirements would need to > change then to say that features of Kernel 5.4 may be used but the code > must still build without error on RHEL 8, or something like that. Yes that's something we had in the past. This has been removed last year: "Compatibility for recent distribution kernels will be kept, notably RHEL/CentOS 7." Does it mean we don't care about RHEL 8 users? If that's what we decide, I'm fine with it.
