Multicast packets, received in XDP to diffrent ports (Trying achieve zoom level performance using XDP)

[atulbari-samespace]

I am trying figure How zoom video call works,
establishing connection with client using QUIC protocol and take that connection in kernel space using KTLS and use XDP to forward packets

wan to achieve, Forward the packet to destinations in kernel space to save lots for processing
Question:
How can I forward, received packet to multiple clients(ports) using XDP or SKB or eBPF
example:
The packets received by socket A are forwarded to socket B and socket C ...

I tried with XDP as
code example on https://duo.com/labs/tech-notes/writing-an-xdp-network-filter-with-ebpf#section8
But not able to multicast

[chaudron]

XDP does not yet support multicasting to multiple interfaces, the following patch is in review:

https://lore.kernel.org/bpf/20210223125809.1376577-7-liuhangbin@gmail.com/

[atulbari-samespace]

@chaudron
I was reading about sk_buff
without using patch If I move to next layer at sk_buff
can achieve this same

[tohojo]

atulbari-samespace <notifications@github.com> writes:

@chaudron I was reading about sk_buff without using patch If I move to next layer at **sk_buff** can achieve this same

No, TC-BPF doesn't support multi-redirect either. If you just want to look at the Quic traffic, why can't you simply use tcpdump or wireshark to dump the traffic?

[atulbari-samespace]

@tohojo thanks for the reply
not just looking at traffic, wan to transmit like The packets received by socket A are forwarded to socket B and socket C ...
I want to transmit the received packet to all connected clients from kernel place, to reduce cpu proceesing (packet transmission in userspace includes more cpu cycles)
like The packets received by socket A are forwarded to socket B and socket C ...

[tohojo]

atulbari-samespace <notifications@github.com> writes:

not just looking at traffic, I want to transmit the received packet to all connected clients from kernel place, to reduce cpu proceesing like The packets received by socket A are forwarded to socket B and socket C ...

Hmm, that's not directly possible with redirecting. I guess since these are UDP packets you could try turning the sockets into multicast listeners and have an XDP program rewrite the destination address to a multicast address as the packets come in...?

[atulbari-samespace]

@tohojo Thanks again and I really appreciate your response.

Okay I am new to the kernel. But here is what I want to do:

1. Client A opens QUIC socket with the server and send video packets.
2. Server sees multiple candidates (client B and Client C) for the packet and want to forward them.
3. but before forwarding server will inspect the packets and decide which ones to forward or drop based on desired resolution and bandwidth constraints. basically I am using SVC codec.
4. I need to decrypt and encrypt before forwarding using KTLS and probably using hardware encryption offload

My goal is to increase the overall capacity of the one server using kernel forwarding.

Thank you!

[tohojo]

atulbari-samespace <notifications@github.com> writes:

@tohojo Thanks again and I really appreciate your response. Okay I am new to the kernel. But here is what I want to do: 1. Client A opens QUIC socket with the server and send video packets. 2. Server sees multiple candidates (client B and Client C) for the packet and want to forward them. 3. but before forwarding server will inspect the packets and decide which ones to forward or drop based on desired resolution and bandwidth constraints. basically I am using SVC codec. 4. I need to decrypt and encrypt before forwarding using KTLS and probably using hardware encryption offload My goal is to increase the overall capacity of the one server using kernel forwarding.

This doesn't sound like a good match for a kernel data path; you're not just duplicating packets, you're logically running multiple sessions to each client, so you need the application to do protocol-level processing for each session. A better fit may be to look at AF_XDP for accelerating the network-to-application data path...