On 11/30/23 2:55 PM, Toke Høiland-Jørgensen wrote:
Daniel Borkmann <daniel@xxxxxxxxxxxxx> writes
On 11/29/23 10:52 PM, Toke Høiland-Jørgensen wrote:
Edward Cree <ecree.xilinx@xxxxxxxxx> writes:
On 28/11/2023 14:39, Toke Høiland-Jørgensen wrote:
I'm not quite sure what should be the semantics of that, though. I.e.,
if you are trying to aggregate two packets that have the flag set, which
packet do you take the value from? What if only one packet has the flag
It would probably make sense if both packets have it set.
Right, so "aggregate only if both packets have the flag set, keeping the
metadata area from the first packet", then?
Yes, sgtm.
set? Or should we instead have a "metadata_xdp_only" flag that just
prevents the skb metadata field from being set entirely?
What would be the use case compared to resetting meta data right before
we return with XDP_PASS?
I was thinking it could save a call to xdp_adjust_meta() to reset it
back to zero before PASSing the packet. But okay, that may be of
marginal utility.
Agree, feels too marginal.
Sounds like what's actually needed is bpf progs inside the GRO engine
to implement the metadata "protocol" prepare and coalesce callbacks?
Hmm, yes, I guess that would be the most general solution :)
Feels like a potential good fit, agree, although for just solving the
above sth not requiring extra BPF might be nice as well.
Yeah, I agree that just the flag makes sense on its own.
-Toke
