Re: XDP CPU maps & shared umem
Magnus Karlsson <[email protected]> Mon, 27 May 2024 07:48:42 +0200
| Newsgroups | org.kernel.vger.xdp-newbies |
|---|---|
| Message-ID | <CAJ8uoz3M6TyYdjvpTOAQ-NyAsyRtj2LR_56NQmhOxyaRyiYRaQ@mail.gmail.com> |
On Sun, 26 May 2024 at 14:48, Yuval El-Hanany <[email protected]> wrote: > > Correction, > the rxq pointer is init=E2=80=99d globally for all frames before = the frame loops, but only the device and the memory information are set fro= m the XDP frame. So still an issue with the queue_index, but the tests on t= he device and memory info in xsk_rcv should be fine. > > Cheers, > Yuval. Hi Yuval, Now I am back. Yes, this seems to be a bug so thank you for spotting it. This is nothing I have ever tested since I thought you would do an XSKMAP redirect to the "right" core first. But there is nothing hindering that someone would do a CPUMAP redirect first then an XSKMAP redirect, so should be supported. So in your analysis, is it only queue_index that needs to be populated at CPUMAP redirect time for this to work? Thanks: Magnus > > On 26 May 2024, at 12:02, Yuval El-Hanany <[email protected]> wrote: > > > > Hi, > > so I=E2=80=99ve dug a bit deeper. It seems the receive queue is not mai= ntained across CPUs and this may make the whole practice of redirecting to = XSK unsafe if I read the code correctly. It also seems this persists to ker= nel 6.6.8. Am I missing something? > > > > The code in cpumap runs XDP programs BUT doesn=E2=80=99t fill the rxq (= see also the TODO comment in the code). The XDP frame is converted to XDP b= uffer but the rxq and txq are not filled. It seems they remain as dangling = pointers. When __xsk_map_redirect is called and in turn xsk_rcv the rxq is = consulted both to check if the umem is shared (in the new patch) as well as= decide whether zero copy is used or not. Since rxq is not valid, I=E2=80= =99m not certain what the outcome is. Once I bypassed umem check, I no long= er crash the kernel but I'm definitely not seeing traffic running. > > > > Thanks, > > Yuval. > > > > Here are the excerpts from the code (5.15.117): > > > > cpumap.c:212 <cpu_map_bpf_prog_run_xdp> =3D=3D=3D=3D=3D Note the commen= t in the code. =3D=3D=3D=3D=3D > > for (i =3D 0; i < n; i++) { > > struct xdp_frame *xdpf =3D frames[i]; > > u32 act; > > int err; > > > > rxq.dev =3D xdpf->dev_rx; > > rxq.mem =3D xdpf->mem; > > /* TODO: report queue_index to xdp_rxq_info */ > > > > xdp_convert_frame_to_buff(xdpf, &xdp); > > > > act =3D bpf_prog_run_xdp(rcpu->prog, &xdp); > > > > xdp.h:175 =3D=3D=3D=3D=3D rxq & txq in the xdp_buff are not filled or e= ven reset. =3D=3D=3D=3D=3D > > static inline > > void xdp_convert_frame_to_buff(struct xdp_frame *frame, struct xdp_buff= *xdp) > > { > > xdp->data_hard_start =3D frame->data - frame->headroom - sizeof(*fra= me); > > xdp->data =3D frame->data; > > xdp->data_end =3D frame->data + frame->len; > > xdp->data_meta =3D frame->data - frame->metasize; > > xdp->frame_sz =3D frame->frame_sz; > > } > > > > xsk.c:269 =3D=3D=3D=3D=3D xsk_rcv consults rxq in xdp_buff which is not= filled! =3D=3D=3D=3D=3D > > static int xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp) > > { > > int err; > > u32 len; > > > > err =3D xsk_rcv_check(xs, xdp); > > if (err) > > return err; > > > > if (xdp->rxq->mem.type =3D=3D MEM_TYPE_XSK_BUFF_POOL) { > > len =3D xdp->data_end - xdp->data; > > return __xsk_rcv_zc(xs, xdp, len); > > } > > > > err =3D __xsk_rcv(xs, xdp); > > if (!err) > > xdp_return_buff(xdp); > > return err; > > } > > > > int __xsk_map_redirect(struct xdp_sock *xs, struct xdp_buff *xdp) > > { > > struct list_head *flush_list =3D this_cpu_ptr(&xskmap_flush_list); > > int err; > > > > err =3D xsk_rcv(xs, xdp); > > if (err) > > return err; > > > > if (!xs->flush_node.prev) > > list_add(&xs->flush_node, flush_list); > > > > return 0; > > } > > > >> On 24 May 2024, at 18:49, Yuval El-Hanany <[email protected]> wrote: > >> > >> CAUTION:External Email, Do not click on links or open attachments unle= ss you recognize the sender and know the content is safe. > >> > >> Hi All, > >> I would really appreciate some guidance here. As this issue span= s both network XDP and CPU map, it=E2=80=99s a bit more difficult for me to= follow in the kernel code. I attempted to trace the issue in the source, b= ut it=E2=80=99s a bit complex to enter existing code base. > >> > >> It will be easier if you can tell me the following: > >> 1. Is the receive queue metadata maintained correctly through the CPU = switch in CPU map? In the description of CPU map in XDP (https://developers= .redhat.com/blog/2021/05/13/receive-side-scaling-rss-with-ebpf-and-cpumap),= it is mentioned that some metadata is not maintained across the CPU switch= , but that would make the umem test problematic. Should I assume the receiv= e queue is maintained? > >> 2. Does XSK umem user code have access to the receive queue metadata m= emory? It seems to be in a different pointer, but it could be that it point= s to the packet headroom in the umem accessible memory. > >> > >> If the receive queue is not maintained across CPU switch then I = think the shared umem test should run along the lines of using some default= receive queue after switching CPUs. Otherwise, it should probably drop pac= kets with invalid receive queues. > >> > >> Thanks, > >> Yuval. > >> > >>> On 20 May 2024, at 18:24, Yuval El-Hanany <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> Short Version > >>> I=E2=80=99ve encountered an issue redirecting traffic to another CPU = while using shared UMEM. The frame arrived at the redirected CPU with inval= id receive queue. This caused a kernel crash on the patch that supports red= irecting to packets to any queue with the same umem due to a test based on = the receive queue. > >>> > >>> Long Version > >>> I=E2=80=99ve created a test program that redirects traffic between tw= o interfaces (replacing the MAC address). See the code below. It starts two= separate processes on two different cores. When directing traffic directly= to an XSK socket all works well. I=E2=80=99m running on kernel 5.15.117 wi= th Magnus patch for shared umem. > >>> > >>> The next step was an XDP program that redirects each packet to the ot= her CPU, and the xdp CPU program redirect the packets to an XDP socket. Ini= tially this resulted in a kernel crash. The reason is that the receive queu= e is not received correctly once the packet switches CPU. > >>> > >>> I=E2=80=99ve patched the kernel so it does sanity check and does not = crash but defaults to queue 0 just for the umem test. > >>> > >>> The kernel no longer crashes but I don=E2=80=99t get the traffic to t= he XSK sockets, and I log the receive queues and they do not seem random: > >>> On first interface: > >>> 0xC1323D50 > >>> 0xC1343D19 > >>> 0xC1343D50 > >>> > >>> On second interface: > >>> 0xC134BD50 > >>> 0xC135BD50 > >>> > >>> Very few bits differences between each of the =E2=80=9Creceive queues= =E2=80=9D. I couldn=E2=80=99t really find something in my program with thos= e or similar values, or in the packets so it makes it less likely it comes = from something I do in userspace. Seems to suggest some flags field? The va= lues are not always the same across reboots but pretty close. > >>> > >>> Am I doing something wrong? It seems pretty basic. Most of the code i= n the XDP program was just added for debugging. The only oddity perhaps is = using the shared umem. > >>> > >>> Thanks, > >>> Yuval. > >>> > >>> I=E2=80=99m attaching the program and values from my "debug map=E2=80= =9D. In the debug map: > >>> 0. Values 0/1 - Which type of program ran (with/without CPU redirecti= on). > >>> 1. Values 2XY - packet redirected from core X to core Y (1st stage). > >>> 2. Values 4XY - packet on core X returns action Y (1st stage). > >>> (These suggest that 1st stage worked correctly). > >>> 3. Values 1XXYY - packet receive queue XX on core YY (XX =3D 10 is in= valid receive queue outside 2..5). > >>> 4. 2XXXX - packet receive queue on any core (XXXX - 4999 imeans queue= greater than 5000). > >>> 5. Random entry - a receive queue. > >>> > >>> Debug map values without CPU redirection: > >>> +------+------+--------------+ > >>> | Port | Key | Received | > >>> +------+------+--------------+ > >>> | 0 | 1032 | 504 | > >>> | 0 | 1024 | 37005992 | > >>> | 0 | 1034 | 37544052 | > >>> | 0 | 0 | 74546875 | > >>> | 1 | 1034 | 35765961 | > >>> | 1 | 0 | 71492773 | > >>> | 1 | 1024 | 35729107 | > >>> | 1 | 1032 | 277 | > >>> +------+------+--------------+ > >>> > >>> Debug map value with CPU redirection (no other change): > >>> +------+------+--------------+ > >>> | Port | Key | Received | > >>> +------+------+--------------+ > >>> | 0 | 1 | 3400 | > >>> | 0 | 223 | 2947 | > >>> | 0 | 232 | 454 | > >>> | 0 | 424 | 454 | > >>> | 0 | 434 | 2947 | > >>> | 0 | 11002 | 454 | > >>> | 0 | 11003 | 2947 | > >>> | 0 | 20000 | 106 | > >>> | 0 | 20016 | 7 | > >>> | 0 | 20024 | 1058 | > >>> | 0 | 20582 | 2 | > >>> | 0 | 24999 | 2231 | > >>> | 0 | 3241295184 | 339 | > >>> | 0 | 3241426201 | 3 | > >>> | 0 | 3241426256 | 1891 | > >>> | 1 | 1 | 1013 | > >>> | 1 | 223 | 610 | > >>> | 1 | 232 | 404 | > >>> | 1 | 424 | 404 | > >>> | 1 | 434 | 610 | > >>> | 1 | 11002 | 404 | > >>> | 1 | 11003 | 610 | > >>> | 1 | 20000 | 17 | > >>> | 1 | 20024 | 309 | > >>> | 1 | 24999 | 689 | > >>> | 1 | 3241459024 | 309 | > >>> | 1 | 3241524560 | 381 | > >>> +------+------+--------------+ > >>> > >>> The XDP code (#if 0 is for the no CPU redirection): > >>> /* SPDX-License-Identifier: GPL-2.0 */ > >>> > >>> #include <linux/if_ether.h> > >>> #include <linux/bpf.h> > >>> #include <linux/in.h> > >>> > >>> #include <bpf/bpf_helpers.h> > >>> #include <bpf/bpf_endian.h> > >>> > >>> #include "xdp/parsing_helpers.h" > >>> > >>> /* Redirect to SP queues map. */ > >>> struct > >>> { > >>> __uint (type, BPF_MAP_TYPE_XSKMAP); > >>> __type (key, __u32); > >>> __type (value, __u32); > >>> __uint (max_entries, 128); > >>> } xsks_map SEC(".maps"); > >>> > >>> /* Redirect to CPUs map. */ > >>> struct > >>> { > >>> __uint (type, BPF_MAP_TYPE_CPUMAP); > >>> __uint (key_size, sizeof (__u32)); > >>> __uint (value_size, sizeof (struct bpf_cpumap_val)); > >>> __uint (max_entries, 32); > >>> } cpu_map SEC(".maps"); > >>> > >>> /* Statistics and debug maps. */ > >>> struct > >>> { > >>> __uint (type, BPF_MAP_TYPE_PERCPU_ARRAY); > >>> __type (key, __u32); > >>> __type (value, __u32); > >>> __uint (max_entries, 64); > >>> } xdp_stats_map SEC(".maps"); > >>> > >>> struct > >>> { > >>> __uint (type, BPF_MAP_TYPE_HASH); > >>> __type (key, __u32); > >>> __type (value, __u32); > >>> __uint (max_entries, 64); > >>> } xdp_debug_proto SEC(".maps"); > >>> > >>> static __u32 oneval =3D 1; > >>> > >>> int my_parse_ethhdr (struct hdr_cursor* nh, void* dataend, struct eth= hdr** eth) > >>> { > >>> __u16 ethtype; > >>> *eth =3D nh->pos; > >>> if ((void*) &(*eth) [1] > dataend) > >>> { > >>> return (-1); > >>> } > >>> > >>> ethtype =3D (*eth)->h_proto; > >>> nh->pos =3D &(*eth) [1]; > >>> if (ethtype =3D=3D bpf_ntohs (ETH_P_8021Q)) > >>> { > >>> struct vlan_hdr* vlan =3D (struct vlan_hdr*) &(*eth) [1]; > >>> if ((void*) &vlan [1] > dataend) > >>> { > >>> return (-1); > >>> } > >>> ethtype =3D vlan->h_vlan_encapsulated_proto; > >>> /* inc_debug_map (10000+(bpf_ntohs (vlan->h_vlan_TCI) & 0x0FFF)); */ > >>> /* inc_debug_map (vlan->h_vlan_TCI); */ > >>> nh->pos =3D &vlan [1]; > >>> } > >>> > >>> return (ethtype); > >>> } > >>> > >>> static void inc_debug_map (__u32 key) > >>> { > >>> #ifdef WITH_STATS > >>> bpf_map_update_elem (&xdp_debug_proto, > >>> &key, (__u32*) &oneval, BPF_NOEXIST); > >>> __u32* rec =3D bpf_map_lookup_elem (&xdp_debug_proto, (__u32*) &key= ); > >>> if (rec !=3D NULL) > >>> { > >>> ++(*rec); > >>> } > >>> #endif > >>> } > >>> > >>> > >>> > >>> SEC ("xdp") > >>> int rdwr_xsk_prog (struct xdp_md *ctx) > >>> { > >>> enum xdp_action action; > >>> int index =3D ctx->rx_queue_index; > >>> void* dataend =3D (void *)(long)ctx->data_end; > >>> void* data =3D (void *)(long)ctx->data; > >>> int stage =3D 0; > >>> > >>> struct hdr_cursor nh; > >>> > >>> __u32 *pkt_count; > >>> struct ethhdr* eth; > >>> > >>> #ifdef WITH_STATS > >>> pkt_count =3D bpf_map_lookup_elem(&xdp_stats_map, &index); > >>> if (pkt_count !=3D NULL) > >>> { > >>> ++*pkt_count; > >>> } > >>> #endif > >>> > >>> /* Parse Ethernet & VLAN */ > >>> nh.pos =3D data; > >>> int ethtype =3D my_parse_ethhdr (&nh, dataend, ð); > >>> if (ethtype !=3D bpf_ntohs (0x0800)) > >>> { > >>> return (XDP_PASS); > >>> } > >>> > >>> /* Direct XSK redirect. */ > >>> #if 0 > >>> inc_debug_map (stage); > >>> action =3D bpf_redirect_map (&xsks_map, index, XDP_PASS); > >>> inc_debug_map (1000 + index*10 + action); > >>> #endif > >>> /* CPU map redirect. */ > >>> __u32 cpuid =3D bpf_get_smp_processor_id (); > >>> __u32 targetcpu =3D cpuid ^ 0x01; > >>> ++stage; > >>> inc_debug_map (stage); > >>> inc_debug_map (200 + cpuid * 10 + targetcpu); > >>> action =3D bpf_redirect_map (&cpu_map, targetcpu, XDP_PASS); > >>> inc_debug_map (400 + targetcpu * 10 + action); > >>> return (action); > >>> } > >>> > >>> SEC ("xdp/cpumap") > >>> int rdwr_cpu_prog(struct xdp_md *ctx) > >>> { > >>> __u64* dataend64 =3D (__u64*) (long) ctx->data_end; > >>> __u64* data64 =3D (__u64*) (long) ctx->data; > >>> __u32 rxqueue =3D ctx->rx_queue_index; > >>> if (rxqueue < 5000) > >>> { > >>> inc_debug_map (20000 + rxqueue); > >>> } > >>> else > >>> { > >>> inc_debug_map (rxqueue); > >>> inc_debug_map (24999); > >>> } > >>> > >>> rxqueue =3D (rxqueue >=3D 2 && rxqueue < 6) ? rxqueue : 10; > >>> __u32 cpuid =3D bpf_get_smp_processor_id (); > >>> cpuid =3D (cpuid < 12) ? cpuid : 20; > >>> inc_debug_map (10000 + 100*rxqueue + cpuid); > >>> > >>> return bpf_redirect_map (&xsks_map, bpf_get_smp_processor_id (), 0)= ; > >>> } > >>> > >> > > >