AF_XDP: No packets from multicast although steered on RX-Queue 0

独自空忆成欢 提交于 2020-03-25 18:42:36

问题


I am still playing with the AF_XDP socket and my program is still largely based on: https://github.com/xdp-project/xdp-tutorial/tree/master/advanced03-AF_XDP

I now want to receive multiple multicast streams (which works fine the way I register the multicast IPs because I have tested it with the default Linux socket thus I am not sharing the code unless you guys say it is necessary to solve the issue).

Because I don't want to change my program to work on multiple RX-Queues of the NIC just yet (go step by step, but eventually I have to do it to increase throughput) I steered the traffic onto a single RX-Queue with this command:

sudo ethtool -N eth20 flow-type udp4 action 0

Filter seems to be active:

$ sudo ethtool -n eth20
48 RX rings available
Total 1 rules

Filter: 1023
        Rule Type: UDP over IPv4
        Src IP addr: 0.0.0.0 mask: 255.255.255.255
        Dest IP addr: 0.0.0.0 mask: 255.255.255.255
        TOS: 0x0 mask: 0xff
        Src port: 0 mask: 0xffff
        Dest port: 0 mask: 0xffff
        Action: Direct to queue 0

But for whatever reason, I receive exactly 0 packets. This is the Kernel-program I am using:

struct bpf_map_def SEC("maps") xsks_map = {
    .type = BPF_MAP_TYPE_XSKMAP,
    .key_size = sizeof(int),
    .value_size = sizeof(int),
    .max_entries = 64,  /* Assume netdev has no more than 64 queues */
};

SEC("xdp_sock")
int xdp_sock_prog(struct xdp_md *ctx) {

    int index = ctx->rx_queue_index;

    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;

    void *pos = data;
    struct ethhdr *eth = (struct ethhdr*)(pos);

    if(eth + sizeof(struct ethhdr) <= data_end) {

        if(bpf_ntohs(eth->h_proto) == ETH_P_IP) {
            struct iphdr *iph = (struct iphdr*)(pos + sizeof(struct ethhdr));

            if(iph + sizeof(struct iphdr) <= data_end) {

                if(iph->protocol == IPPROTO_UDP) {
                    const __u16 iph_sz_in_bytes = iph->ihl * 4;

                    if(iph + iph_sz_in_bytes <= data_end) {
                        struct udphdr *udh = (struct udphdr*)(pos + sizeof(struct ethhdr) + iph_sz_in_bytes);

                        if(udh + sizeof(struct udphdr) <= data_end) {

                            if (bpf_map_lookup_elem(&xsks_map, &index)) {
                                return bpf_redirect_map(&xsks_map, index, 0);
                            }
                        }
                    }
                }
            }
        }
    }

    return XDP_PASS;
}

Any ideas why?

Edit:

I changed:

                    if (bpf_map_lookup_elem(&xsks_map, &index)) {
                        const int ret_val = bpf_redirect_map(&xsks_map, index, 0);
                        bpf_printk("RET-VAL: %d\n", ret_val);
                        return ret_val;
                    }

and did

sudo cat /sys/kernel/debug/tracing/trace_pipe

which returns:

ksoftirqd/17-98 [017] ..s. 277979.654041: 0: RET-VAL: 4

According to the description of bpf_redirect_map:

  • Returns * XDP_REDIRECT on success, or the value of the two lower bits * of the **flags* argument on error.

Because XDP_REDIRECT = 4 I assume this works as expected.

Furthermore, I added this output in the user-space code in main() after parsing of command line arguments has happened:

printf("RX-Queue: %d\n", cfg.xsk_if_queue);

Which indeed returns 0 (so correct RX-Queue is selected).

Edit_2: The strange thing is that I was able to receive a single multicast stream before (which somehow ended up on RX-Queue 0 by accident) but after executing the ethtool-command above I am not receiving anything at all. Sounds strange but that's how I observed it.

Edit_3: sudo ethtool -S eth20 returned: http://ix.io/2cSC

$ sudo bpftool prog show
39: cgroup_skb  tag 7be49e3934a125ba  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 38,39
40: cgroup_skb  tag 2a142ef67aaad174  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 38,39
41: cgroup_skb  tag 7be49e3934a125ba  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 40,41
42: cgroup_skb  tag 2a142ef67aaad174  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 40,41
43: cgroup_skb  tag 7be49e3934a125ba  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 42,43
44: cgroup_skb  tag 2a142ef67aaad174  gpl
        loaded_at 2020-02-28T08:00:06+0000  uid 0
        xlated 296B  not jited  memlock 4096B  map_ids 42,43

回答1:


There was indeed a problem in my user-space code. I polled the filedescriptor of the socket even though I disabled polling. Because of that it never returned.



来源:https://stackoverflow.com/questions/60436246/af-xdp-no-packets-from-multicast-although-steered-on-rx-queue-0

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!