[...] > > In general I see no reason to populate these fields before the XDP > program runs. Someone needs to convince me why having frags info before > program runs is useful. In general headers should be preserved and first > frag already included in the data pointers. If users start parsing further > they might need it, but this series doesn't provide a way to do that > so IMO without those helpers its a bit difficult to debate. We need to populate the skb_shared_info before running the xdp program in order to allow the ebpf sanbox to access this data. If we restrict the access to the first buffer only I guess we can avoid to do that but I think there is a value allowing the xdp program to access this data. A possible optimization can be access the shared_info only once before running the ebpf program constructing the shared_info using a struct allocated on the stack. Moreover we can define a "xdp_shared_info" struct to alias the skb_shared_info one in order to have most on frags elements in the first "shared_info" cache line. > > Specifically for XDP_TX case we can just flip the descriptors from RX > ring to TX ring and keep moving along. This is going to be ideal on > 40/100Gbps nics. > > I'm not arguing that its likely possible to put some prefetch logic > in there and keep the pipe full, but I would need to see that on > a 100gbps nic to be convinced the details here are going to work. Or > at minimum a 40gbps nic. > > > > > [...] > Not against it, but these things are a bit tricky. Couple things I still > want to see/understand > > - Lets see a 40gbps use a prefetch and verify it works in practice > - Explain why we can't just do this after XDP program runs how can we allow the ebpf program to access paged data if we do not do that? > - How will we read data in the frag list if we need to parse headers > inside the frags[]. > > The above would be best to answer now rather than later IMO. > > Thanks, > John Regards, Lorenzo
Attachment:
signature.asc
Description: PGP signature
