On 11/9/22 11:44 PM, Stanislav Fomichev wrote:
>>> @@ -423,14 +425,25 @@ XDP_METADATA_KFUNC_xxx
>>> MAX_XDP_METADATA_KFUNC,
>>> };
>>>
>>> +struct xdp_to_skb_metadata {
>>> + u32 magic; /* xdp_metadata_magic */
>>> + u64 rx_timestamp;
>>
>> Slightly confused. I thought/think most drivers populate the skb timestamp
>> if they can already? So why do we need to bounce these through some xdp
>> metadata? Won't all this cost more than the load/store directly from the
>> descriptor into the skb? Even if drivers are not populating skb now
>> shouldn't an ethtool knob be enough to turn this on?
>
> dsahern@ pointed out that it might be useful for the program to be
> able to override some of that metadata.
Examples that come to mind from previous work:
1. changing vlans on a redirect: Rx on vlan 1 with h/w popping the vlan
so it is provided in metadata. Then on a redirect it shifts to vlan 2
for Tx. But this example use case assumes Tx accesses the metadata to
ask h/w to insert the header.
2. popping or updating an encap header and wanting to update the checksum
3. changing the h/w provided hash to affect steering of a subsequent skb
