Lorenzo Bianconi wrote: > [...] > > > > > 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. I agree. We could also only populate the fields if the program accesses the fields. > 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. Seems interesting, might be a good idea. > 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? I don't see an easy way, but also this series doesn't have the data access support. Its hard to tell until we get at least a 40gbps nic if my concern about performance is real or not. Prefetching smartly could resolve some of the issue I guess. If the Intel folks are working on it I think waiting would be great. Otherwise at minimum drop the helpers and be prepared to revert things if needed. > > > - 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
