processing packets without forwarding

[radoslawc]

Hi there,
First of all thank you for making this code available.
I have question regarding processing packets, how would one go with only receiving packets to further process them? Or rather what will be a good way to discard "used" packets from ring safely? This is were my problem is I think.
Using example l2fwd-1link.rs if I replace forward function with

fn write_pcap(bufs: &mut ArrayDeque<[Buf<BufCustom>; PENDING_LEN], Wrapping>) -> Result<(), ()> {
    let file = File::create("out.pcap").expect("Error creating file");
    let mut pcap_writer = PcapWriter::new(file).unwrap();
    for buf in bufs {
    pcap_writer.write(1, 0, &buf.data, buf.data.len() as u32).unwrap();
    }

    Ok(())
}

everything works as expected up until fq_bufs reach 2048 limit.

Any help appreciated.

Thanks in advance
Rado

[dansiemon]

Hello, DAF_XDP requires that userspace continually refill the socket so the NIC has somewhere to write packets. The 1link sample returns the buffers based on getting them back from the kernel after they are transmitted (they come back on the completion queue after they are sent). If you aren't transmitting them, you'll need to return the buffer to the pool directly. That is, add them back to 'bufs' in the main loop (not the bufs in the forward / write_pcap as that's a temporary area). Adding a 'consuming' example is a good idea. Thanks.

…

On Tue, 5 May 2020 at 10:01, Radek ***@***.***> wrote: Hi there, First of all thank you for making this code available. I have question regarding processing packets, how would one go with only receiving packets to further process them? Or rather what will be a good way to discard "used" packets from ring safely? This is were my problem is I think. Using example l2fwd-1link.rs if I replace forward function with fn write_pcap(bufs: &mut ArrayDeque<[Buf<BufCustom>; PENDING_LEN], Wrapping>) -> Result<(), ()> { let file = File::create("out.pcap").expect("Error creating file"); let mut pcap_writer = PcapWriter::new(file).unwrap(); for buf in bufs { pcap_writer.write(1, 0, &buf.data, buf.data.len() as u32).unwrap(); } Ok(()) } everything works as expected up until fq_bufs reach 2048 limit. Any help appreciated. Thanks in advance Rado — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2Q6YXH7RSEFYPB6JDOTRDRQAL3DANCNFSM4MZTFFVA> .

[gopakumarce]

@dansiemon Thx for creating this lib. But for the l2fwd-2link example to work, doesnt it also need insertion of a bfp program into the kernel, that has to be setup seperately before running l2fwd-2link right ?

[ I am trying to use XDP in https://github.com/gopakumarce/R2 and hence the question]

[dansiemon]

No, libbpf installs a small BPF program to redirect to the socket automatically. The example programs work standalone. What NIC are you trying to use?

I discovered R2 a couple weeks back. I haven't had a chance to dig in but it looks interesting.

In the last few months I've had to put the afxdp-rs work on hold but that will change in the coming weeks. Lots to do.

[gopakumarce]

Thx for the response. I was trying the l2fwd-2link example on two sets of veth interfaces vethA-1---vethA-2 =l2fwd= vethB-1--vethB-2 -- and I told l2fwd to send from vethA-2 to veth-B1 .. and I ping from veth-A1, I do see ethtool bpf_queue_0 Rx stats on vethA-2 but I dont see any Tx stats on vethA-2 or any Rx stats on vethB-1 and tcpdump doesnt show anything on vethB-2 - and hence the reason I thought maybe I need to load some bpf program into the kernel

[dansiemon]

I've only tried to use AF_XDP with i40e (Intel 710) NICs in zero copy mode.

I believe that XDP happens below the point where tcpdump gets packets so you won't see them there.

[dansiemon]

I've added a dump example which consumes and doesn't forward. Testing this found a bug which is probably what you were hitting when receiving packets stopped at 2048.

[radoslawc]

I've added a dump example which consumes and doesn't forward. Testing this found a bug which is probably what you were hitting when receiving packets stopped at 2048.

Cool, thank you! I'll test that out.