[xdp-hints] Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[xdp-hints] Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Jesper Dangaard Brouer]

Hi Stanislav,

Sharing that Intel (+Red Hat) have an interest in getting XDP metadata
hints working on smaller devices used for "Edge Controls for Industrial"
(ECI)[1].

What are your plans for your patchset[2] ?

My suggestion (to Intel) is that we implement the TX-timestamp (plus
LaunchTime) on top of Stanslav's patches[2].  For drivers igc+igb+stmmac
which I think will cover the tests[3] need by Arun/Costin (?). And then
post it upstream for review.

The Intel test tool[3] isn't open, but it is an AF_XDP based Real-Time
Compute Performance (RTCP) application that show-case a real-time
control loop application.  The current code uses out-of-tree[4] "TXTIME"
LaunchTime feature, that want not upstreamed.

Lets us instead implement a proper TX LaunchTime feature on top of [2].

--Jesper
cc. XDP-hints ML as anyone is free to code this up, code help here[5]


[1] https://eci.intel.com/
[2] https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com/
[3] https://github.com/OTCShare2/rtcp-xdp
[4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
[5] 
https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Stanislav Fomichev]

On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
> Hi Stanislav,
>
> Sharing that Intel (+Red Hat) have an interest in getting XDP metadata
> hints working on smaller devices used for "Edge Controls for Industrial"
> (ECI)[1].
>
> What are your plans for your patchset[2] ?

Sorry, I was OOO for two weeks and then got distracted by some internal work :-(
I'll probably post another respin next week. I think I've addressed
most of the Maciej's feedback, but the only thing that we need to move
this forward is to support another device besides mlx5. Maciej was
suggesting ice, but I don't have the hw :-( I have some idfp-capable
devices, so I'll probably try to play with it instead (but the idpf
driver is still not pulled).

So if you want to help speed it up, we should probably focus first on
getting some of the intel nics support tx metadata.
To proceed, maybe I should post my next iteration and we can
collaborate on the ice driver changes?
Who should I CC explicitly?

> My suggestion (to Intel) is that we implement the TX-timestamp (plus
> LaunchTime) on top of Stanslav's patches[2].  For drivers igc+igb+stmmac
> which I think will cover the tests[3] need by Arun/Costin (?). And then
> post it upstream for review.
>
> The Intel test tool[3] isn't open, but it is an AF_XDP based Real-Time
> Compute Performance (RTCP) application that show-case a real-time
> control loop application.  The current code uses out-of-tree[4] "TXTIME"
> LaunchTime feature, that want not upstreamed.
>
> Lets us instead implement a proper TX LaunchTime feature on top of [2].
>
> --Jesper
> cc. XDP-hints ML as anyone is free to code this up, code help here[5]
>
>
> [1] https://eci.intel.com/
> [2] https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com/
> [3] https://github.com/OTCShare2/rtcp-xdp
> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
> [5]
> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Song, Yoong Siang]

On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev <sdf@google.com> wrote:
>On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer <hawk@kernel.org>
>wrote:
>>
>> Hi Stanislav,
>>
>> Sharing that Intel (+Red Hat) have an interest in getting XDP metadata
>> hints working on smaller devices used for "Edge Controls for Industrial"
>> (ECI)[1].
>>
>> What are your plans for your patchset[2] ?
>
>Sorry, I was OOO for two weeks and then got distracted by some internal work :-
>( I'll probably post another respin next week. I think I've addressed most of the
>Maciej's feedback, but the only thing that we need to move this forward is to
>support another device besides mlx5. Maciej was suggesting ice, but I don't have
>the hw :-( I have some idfp-capable devices, so I'll probably try to play with it
>instead (but the idpf driver is still not pulled).
>
>So if you want to help speed it up, we should probably focus first on getting some
>of the intel nics support tx metadata.
>To proceed, maybe I should post my next iteration and we can collaborate on the
>ice driver changes?
>Who should I CC explicitly?
>
Hi Stanislav,

I can help to speed it up. I don't have ice HW on my hand as well, so maybe we can start 
with igc drivers, followed by stmmac drivers.

Please post your next iteration, then we can collaborate based on that.

Thanks & Regards
Siang

>> My suggestion (to Intel) is that we implement the TX-timestamp (plus
>> LaunchTime) on top of Stanslav's patches[2].  For drivers
>> igc+igb+stmmac which I think will cover the tests[3] need by
>> Arun/Costin (?). And then post it upstream for review.
>>
>> The Intel test tool[3] isn't open, but it is an AF_XDP based Real-Time
>> Compute Performance (RTCP) application that show-case a real-time
>> control loop application.  The current code uses out-of-tree[4] "TXTIME"
>> LaunchTime feature, that want not upstreamed.
>>
>> Lets us instead implement a proper TX LaunchTime feature on top of [2].
>>
>> --Jesper
>> cc. XDP-hints ML as anyone is free to code this up, code help here[5]
>>
>>
>> [1] https://eci.intel.com/
>> [2]
>> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com/
>> [3] https://github.com/OTCShare2/rtcp-xdp
>> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
>> [5]
>> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code0
>> 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Stanislav Fomichev]

On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
<yoong.siang.song@intel.com> wrote:
>
> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev <sdf@google.com> wrote:
> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer <hawk@kernel.org>
> >wrote:
> >>
> >> Hi Stanislav,
> >>
> >> Sharing that Intel (+Red Hat) have an interest in getting XDP metadata
> >> hints working on smaller devices used for "Edge Controls for Industrial"
> >> (ECI)[1].
> >>
> >> What are your plans for your patchset[2] ?
> >
> >Sorry, I was OOO for two weeks and then got distracted by some internal work :-
> >( I'll probably post another respin next week. I think I've addressed most of the
> >Maciej's feedback, but the only thing that we need to move this forward is to
> >support another device besides mlx5. Maciej was suggesting ice, but I don't have
> >the hw :-( I have some idfp-capable devices, so I'll probably try to play with it
> >instead (but the idpf driver is still not pulled).
> >
> >So if you want to help speed it up, we should probably focus first on getting some
> >of the intel nics support tx metadata.
> >To proceed, maybe I should post my next iteration and we can collaborate on the
> >ice driver changes?
> >Who should I CC explicitly?
> >
> Hi Stanislav,
>
> I can help to speed it up. I don't have ice HW on my hand as well, so maybe we can start
> with igc drivers, followed by stmmac drivers.
>
> Please post your next iteration, then we can collaborate based on that.

Awesome, thanks! The v2 is out, you're on the CC. Feel free to reach
out directly if you have any questions or suggestions.

I also have to abaon my idea of playing with idpf since the driver
that's posted on the list doesn't have af_xdp support :-(


> Thanks & Regards
> Siang
>
> >> My suggestion (to Intel) is that we implement the TX-timestamp (plus
> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
> >> igc+igb+stmmac which I think will cover the tests[3] need by
> >> Arun/Costin (?). And then post it upstream for review.
> >>
> >> The Intel test tool[3] isn't open, but it is an AF_XDP based Real-Time
> >> Compute Performance (RTCP) application that show-case a real-time
> >> control loop application.  The current code uses out-of-tree[4] "TXTIME"
> >> LaunchTime feature, that want not upstreamed.
> >>
> >> Lets us instead implement a proper TX LaunchTime feature on top of [2].
> >>
> >> --Jesper
> >> cc. XDP-hints ML as anyone is free to code this up, code help here[5]
> >>
> >>
> >> [1] https://eci.intel.com/
> >> [2]
> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com/
> >> [3] https://github.com/OTCShare2/rtcp-xdp
> >> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
> >> [5]
> >> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code0
> >> 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Song, Yoong Siang]

On Friday, September 15, 2023 5:06 AM, Stanislav Fomichev <sdf@google.com> wrote:
>On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
><yoong.siang.song@intel.com> wrote:
>>
>> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev
><sdf@google.com> wrote:
>> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer
>> ><hawk@kernel.org>
>> >wrote:
>> >>
>> >> Hi Stanislav,
>> >>
>> >> Sharing that Intel (+Red Hat) have an interest in getting XDP
>> >> metadata hints working on smaller devices used for "Edge Controls for
>Industrial"
>> >> (ECI)[1].
>> >>
>> >> What are your plans for your patchset[2] ?
>> >
>> >Sorry, I was OOO for two weeks and then got distracted by some
>> >internal work :- ( I'll probably post another respin next week. I
>> >think I've addressed most of the Maciej's feedback, but the only
>> >thing that we need to move this forward is to support another device
>> >besides mlx5. Maciej was suggesting ice, but I don't have the hw :-(
>> >I have some idfp-capable devices, so I'll probably try to play with it instead (but
>the idpf driver is still not pulled).
>> >
>> >So if you want to help speed it up, we should probably focus first on
>> >getting some of the intel nics support tx metadata.
>> >To proceed, maybe I should post my next iteration and we can
>> >collaborate on the ice driver changes?
>> >Who should I CC explicitly?
>> >
>> Hi Stanislav,
>>
>> I can help to speed it up. I don't have ice HW on my hand as well, so
>> maybe we can start with igc drivers, followed by stmmac drivers.
>>
>> Please post your next iteration, then we can collaborate based on that.
>
>Awesome, thanks! The v2 is out, you're on the CC. Feel free to reach out directly
>if you have any questions or suggestions.

Hi Stanislav,

Thanks for the v2. I do have one question. What is the code base which you are using?
When I try to apply your v2 patch set on top of latest net-next, there are few merge conflicts,
and it seem like Rx Metadata is not included in your base.

Thanks & Regards
Siang
 
>
>I also have to abaon my idea of playing with idpf since the driver that's posted on
>the list doesn't have af_xdp support :-(
>
>
>> Thanks & Regards
>> Siang
>>
>> >> My suggestion (to Intel) is that we implement the TX-timestamp
>> >> (plus
>> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
>> >> igc+igb+stmmac which I think will cover the tests[3] need by
>> >> Arun/Costin (?). And then post it upstream for review.
>> >>
>> >> The Intel test tool[3] isn't open, but it is an AF_XDP based
>> >> Real-Time Compute Performance (RTCP) application that show-case a
>> >> real-time control loop application.  The current code uses out-of-tree[4]
>"TXTIME"
>> >> LaunchTime feature, that want not upstreamed.
>> >>
>> >> Lets us instead implement a proper TX LaunchTime feature on top of [2].
>> >>
>> >> --Jesper
>> >> cc. XDP-hints ML as anyone is free to code this up, code help
>> >> here[5]
>> >>
>> >>
>> >> [1] https://eci.intel.com/
>> >> [2]
>> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com
>> >> / [3] https://github.com/OTCShare2/rtcp-xdp
>> >> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
>> >> [5]
>> >> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/co
>> >> de0 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Stanislav Fomichev]

On Wed, Sep 20, 2023 at 7:10 PM Song, Yoong Siang
<yoong.siang.song@intel.com> wrote:
>
> On Friday, September 15, 2023 5:06 AM, Stanislav Fomichev <sdf@google.com> wrote:
> >On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
> ><yoong.siang.song@intel.com> wrote:
> >>
> >> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev
> ><sdf@google.com> wrote:
> >> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer
> >> ><hawk@kernel.org>
> >> >wrote:
> >> >>
> >> >> Hi Stanislav,
> >> >>
> >> >> Sharing that Intel (+Red Hat) have an interest in getting XDP
> >> >> metadata hints working on smaller devices used for "Edge Controls for
> >Industrial"
> >> >> (ECI)[1].
> >> >>
> >> >> What are your plans for your patchset[2] ?
> >> >
> >> >Sorry, I was OOO for two weeks and then got distracted by some
> >> >internal work :- ( I'll probably post another respin next week. I
> >> >think I've addressed most of the Maciej's feedback, but the only
> >> >thing that we need to move this forward is to support another device
> >> >besides mlx5. Maciej was suggesting ice, but I don't have the hw :-(
> >> >I have some idfp-capable devices, so I'll probably try to play with it instead (but
> >the idpf driver is still not pulled).
> >> >
> >> >So if you want to help speed it up, we should probably focus first on
> >> >getting some of the intel nics support tx metadata.
> >> >To proceed, maybe I should post my next iteration and we can
> >> >collaborate on the ice driver changes?
> >> >Who should I CC explicitly?
> >> >
> >> Hi Stanislav,
> >>
> >> I can help to speed it up. I don't have ice HW on my hand as well, so
> >> maybe we can start with igc drivers, followed by stmmac drivers.
> >>
> >> Please post your next iteration, then we can collaborate based on that.
> >
> >Awesome, thanks! The v2 is out, you're on the CC. Feel free to reach out directly
> >if you have any questions or suggestions.
>
> Hi Stanislav,
>
> Thanks for the v2. I do have one question. What is the code base which you are using?
> When I try to apply your v2 patch set on top of latest net-next, there are few merge conflicts,
> and it seem like Rx Metadata is not included in your base.

Anything prior to my recent commit "bpf: make it easier to add new
metadata kfunc" should work. That's most likely the reason it
conflicts.
So try to cherry pick it on top of the following and let me know if
you still have an issue; I can rebase and repost:
5c04433daf9e - bpf: Charge modmem for struct_ops trampoline (6 days
ago) <Song Liu>

Regarding rx metadata: it's separate from af_xdp and it's more
generically implemented in the xdp layer, see:
Documentation/networking/xdp-rx-metadata.rst

Also see tools/testing/selftests/bpf/prog_tests/xdp_metadata.c for an
example on how to use both rx and tx sides.

> Thanks & Regards
> Siang
>
> >
> >I also have to abaon my idea of playing with idpf since the driver that's posted on
> >the list doesn't have af_xdp support :-(
> >
> >
> >> Thanks & Regards
> >> Siang
> >>
> >> >> My suggestion (to Intel) is that we implement the TX-timestamp
> >> >> (plus
> >> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
> >> >> igc+igb+stmmac which I think will cover the tests[3] need by
> >> >> Arun/Costin (?). And then post it upstream for review.
> >> >>
> >> >> The Intel test tool[3] isn't open, but it is an AF_XDP based
> >> >> Real-Time Compute Performance (RTCP) application that show-case a
> >> >> real-time control loop application.  The current code uses out-of-tree[4]
> >"TXTIME"
> >> >> LaunchTime feature, that want not upstreamed.
> >> >>
> >> >> Lets us instead implement a proper TX LaunchTime feature on top of [2].
> >> >>
> >> >> --Jesper
> >> >> cc. XDP-hints ML as anyone is free to code this up, code help
> >> >> here[5]
> >> >>
> >> >>
> >> >> [1] https://eci.intel.com/
> >> >> [2]
> >> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.com
> >> >> / [3] https://github.com/OTCShare2/rtcp-xdp
> >> >> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
> >> >> [5]
> >> >> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/co
> >> >> de0 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Song, Yoong Siang]

On Thursday, September 21, 2023 12:36 PM, Stanislav Fomichev <sdf@google.com> wrote:
>On Wed, Sep 20, 2023 at 7:10 PM Song, Yoong Siang
><yoong.siang.song@intel.com> wrote:
>>
>> On Friday, September 15, 2023 5:06 AM, Stanislav Fomichev <sdf@google.com>
>wrote:
>> >On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
>> ><yoong.siang.song@intel.com> wrote:
>> >>
>> >> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev
>> ><sdf@google.com> wrote:
>> >> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer
>> >> ><hawk@kernel.org>
>> >> >wrote:
>> >> >>
>> >> >> Hi Stanislav,
>> >> >>
>> >> >> Sharing that Intel (+Red Hat) have an interest in getting XDP
>> >> >> metadata hints working on smaller devices used for "Edge
>> >> >> Controls for
>> >Industrial"
>> >> >> (ECI)[1].
>> >> >>
>> >> >> What are your plans for your patchset[2] ?
>> >> >
>> >> >Sorry, I was OOO for two weeks and then got distracted by some
>> >> >internal work :- ( I'll probably post another respin next week. I
>> >> >think I've addressed most of the Maciej's feedback, but the only
>> >> >thing that we need to move this forward is to support another
>> >> >device besides mlx5. Maciej was suggesting ice, but I don't have
>> >> >the hw :-( I have some idfp-capable devices, so I'll probably try
>> >> >to play with it instead (but
>> >the idpf driver is still not pulled).
>> >> >
>> >> >So if you want to help speed it up, we should probably focus first
>> >> >on getting some of the intel nics support tx metadata.
>> >> >To proceed, maybe I should post my next iteration and we can
>> >> >collaborate on the ice driver changes?
>> >> >Who should I CC explicitly?
>> >> >
>> >> Hi Stanislav,
>> >>
>> >> I can help to speed it up. I don't have ice HW on my hand as well,
>> >> so maybe we can start with igc drivers, followed by stmmac drivers.
>> >>
>> >> Please post your next iteration, then we can collaborate based on that.
>> >
>> >Awesome, thanks! The v2 is out, you're on the CC. Feel free to reach
>> >out directly if you have any questions or suggestions.
>>
>> Hi Stanislav,
>>
>> Thanks for the v2. I do have one question. What is the code base which you are
>using?
>> When I try to apply your v2 patch set on top of latest net-next, there
>> are few merge conflicts, and it seem like Rx Metadata is not included in your
>base.
>
>Anything prior to my recent commit "bpf: make it easier to add new metadata
>kfunc" should work. That's most likely the reason it conflicts.
>So try to cherry pick it on top of the following and let me know if you still have an
>issue; I can rebase and repost:
>5c04433daf9e - bpf: Charge modmem for struct_ops trampoline (6 days
>ago) <Song Liu>

This base work for me. Thanks.
Btw, how we should collaborate?
After done coding and testing on my side, I send you my patches, 
then you will include them into your patchset v3? 

>
>Regarding rx metadata: it's separate from af_xdp and it's more generically
>implemented in the xdp layer, see:
>Documentation/networking/xdp-rx-metadata.rst
>
>Also see tools/testing/selftests/bpf/prog_tests/xdp_metadata.c for an example
>on how to use both rx and tx sides.
>
>> Thanks & Regards
>> Siang
>>
>> >
>> >I also have to abaon my idea of playing with idpf since the driver
>> >that's posted on the list doesn't have af_xdp support :-(
>> >
>> >
>> >> Thanks & Regards
>> >> Siang
>> >>
>> >> >> My suggestion (to Intel) is that we implement the TX-timestamp
>> >> >> (plus
>> >> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
>> >> >> igc+igb+stmmac which I think will cover the tests[3] need by
>> >> >> Arun/Costin (?). And then post it upstream for review.
>> >> >>
>> >> >> The Intel test tool[3] isn't open, but it is an AF_XDP based
>> >> >> Real-Time Compute Performance (RTCP) application that show-case
>> >> >> a real-time control loop application.  The current code uses
>> >> >> out-of-tree[4]
>> >"TXTIME"
>> >> >> LaunchTime feature, that want not upstreamed.
>> >> >>
>> >> >> Lets us instead implement a proper TX LaunchTime feature on top of [2].
>> >> >>
>> >> >> --Jesper
>> >> >> cc. XDP-hints ML as anyone is free to code this up, code help
>> >> >> here[5]
>> >> >>
>> >> >>
>> >> >> [1] https://eci.intel.com/
>> >> >> [2]
>> >> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.
>> >> >> com / [3] https://github.com/OTCShare2/rtcp-xdp
>> >> >> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
>> >> >> [5]
>> >> >> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn
>> >> >> /co
>> >> >> de0
>> >> >> 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Stanislav Fomichev]

On Thu, Sep 21, 2023 at 1:17 AM Song, Yoong Siang
<yoong.siang.song@intel.com> wrote:
>
> On Thursday, September 21, 2023 12:36 PM, Stanislav Fomichev <sdf@google.com> wrote:
> >On Wed, Sep 20, 2023 at 7:10 PM Song, Yoong Siang
> ><yoong.siang.song@intel.com> wrote:
> >>
> >> On Friday, September 15, 2023 5:06 AM, Stanislav Fomichev <sdf@google.com>
> >wrote:
> >> >On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
> >> ><yoong.siang.song@intel.com> wrote:
> >> >>
> >> >> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev
> >> ><sdf@google.com> wrote:
> >> >> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer
> >> >> ><hawk@kernel.org>
> >> >> >wrote:
> >> >> >>
> >> >> >> Hi Stanislav,
> >> >> >>
> >> >> >> Sharing that Intel (+Red Hat) have an interest in getting XDP
> >> >> >> metadata hints working on smaller devices used for "Edge
> >> >> >> Controls for
> >> >Industrial"
> >> >> >> (ECI)[1].
> >> >> >>
> >> >> >> What are your plans for your patchset[2] ?
> >> >> >
> >> >> >Sorry, I was OOO for two weeks and then got distracted by some
> >> >> >internal work :- ( I'll probably post another respin next week. I
> >> >> >think I've addressed most of the Maciej's feedback, but the only
> >> >> >thing that we need to move this forward is to support another
> >> >> >device besides mlx5. Maciej was suggesting ice, but I don't have
> >> >> >the hw :-( I have some idfp-capable devices, so I'll probably try
> >> >> >to play with it instead (but
> >> >the idpf driver is still not pulled).
> >> >> >
> >> >> >So if you want to help speed it up, we should probably focus first
> >> >> >on getting some of the intel nics support tx metadata.
> >> >> >To proceed, maybe I should post my next iteration and we can
> >> >> >collaborate on the ice driver changes?
> >> >> >Who should I CC explicitly?
> >> >> >
> >> >> Hi Stanislav,
> >> >>
> >> >> I can help to speed it up. I don't have ice HW on my hand as well,
> >> >> so maybe we can start with igc drivers, followed by stmmac drivers.
> >> >>
> >> >> Please post your next iteration, then we can collaborate based on that.
> >> >
> >> >Awesome, thanks! The v2 is out, you're on the CC. Feel free to reach
> >> >out directly if you have any questions or suggestions.
> >>
> >> Hi Stanislav,
> >>
> >> Thanks for the v2. I do have one question. What is the code base which you are
> >using?
> >> When I try to apply your v2 patch set on top of latest net-next, there
> >> are few merge conflicts, and it seem like Rx Metadata is not included in your
> >base.
> >
> >Anything prior to my recent commit "bpf: make it easier to add new metadata
> >kfunc" should work. That's most likely the reason it conflicts.
> >So try to cherry pick it on top of the following and let me know if you still have an
> >issue; I can rebase and repost:
> >5c04433daf9e - bpf: Charge modmem for struct_ops trampoline (6 days
> >ago) <Song Liu>
>
> This base work for me. Thanks.
> Btw, how we should collaborate?
> After done coding and testing on my side, I send you my patches,
> then you will include them into your patchset v3?

Yeah, that works for me. Unless you have better ideas :-)

> >Regarding rx metadata: it's separate from af_xdp and it's more generically
> >implemented in the xdp layer, see:
> >Documentation/networking/xdp-rx-metadata.rst
> >
> >Also see tools/testing/selftests/bpf/prog_tests/xdp_metadata.c for an example
> >on how to use both rx and tx sides.
> >
> >> Thanks & Regards
> >> Siang
> >>
> >> >
> >> >I also have to abaon my idea of playing with idpf since the driver
> >> >that's posted on the list doesn't have af_xdp support :-(
> >> >
> >> >
> >> >> Thanks & Regards
> >> >> Siang
> >> >>
> >> >> >> My suggestion (to Intel) is that we implement the TX-timestamp
> >> >> >> (plus
> >> >> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
> >> >> >> igc+igb+stmmac which I think will cover the tests[3] need by
> >> >> >> Arun/Costin (?). And then post it upstream for review.
> >> >> >>
> >> >> >> The Intel test tool[3] isn't open, but it is an AF_XDP based
> >> >> >> Real-Time Compute Performance (RTCP) application that show-case
> >> >> >> a real-time control loop application.  The current code uses
> >> >> >> out-of-tree[4]
> >> >"TXTIME"
> >> >> >> LaunchTime feature, that want not upstreamed.
> >> >> >>
> >> >> >> Lets us instead implement a proper TX LaunchTime feature on top of [2].
> >> >> >>
> >> >> >> --Jesper
> >> >> >> cc. XDP-hints ML as anyone is free to code this up, code help
> >> >> >> here[5]
> >> >> >>
> >> >> >>
> >> >> >> [1] https://eci.intel.com/
> >> >> >> [2]
> >> >> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.
> >> >> >> com / [3] https://github.com/OTCShare2/rtcp-xdp
> >> >> >> [4] https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
> >> >> >> [5]
> >> >> >> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn
> >> >> >> /co
> >> >> >> de0
> >> >> >> 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc

[xdp-hints] Re: Interest in TX-side XDP metadata hints from Intel (+ Red Hat)

[Song, Yoong Siang]

On Friday, September 22, 2023 12:24 AM, Stanislav Fomichev <sdf@google.com> wrote:
>On Thu, Sep 21, 2023 at 1:17 AM Song, Yoong Siang
><yoong.siang.song@intel.com> wrote:
>>
>> On Thursday, September 21, 2023 12:36 PM, Stanislav Fomichev
><sdf@google.com> wrote:
>> >On Wed, Sep 20, 2023 at 7:10 PM Song, Yoong Siang
>> ><yoong.siang.song@intel.com> wrote:
>> >>
>> >> On Friday, September 15, 2023 5:06 AM, Stanislav Fomichev
>> >> <sdf@google.com>
>> >wrote:
>> >> >On Wed, Sep 13, 2023 at 6:22 PM Song, Yoong Siang
>> >> ><yoong.siang.song@intel.com> wrote:
>> >> >>
>> >> >> On Saturday, September 9, 2023 12:38 AM Stanislav Fomichev
>> >> ><sdf@google.com> wrote:
>> >> >> >On Fri, Sep 8, 2023 at 7:18 AM Jesper Dangaard Brouer
>> >> >> ><hawk@kernel.org>
>> >> >> >wrote:
>> >> >> >>
>> >> >> >> Hi Stanislav,
>> >> >> >>
>> >> >> >> Sharing that Intel (+Red Hat) have an interest in getting XDP
>> >> >> >> metadata hints working on smaller devices used for "Edge
>> >> >> >> Controls for
>> >> >Industrial"
>> >> >> >> (ECI)[1].
>> >> >> >>
>> >> >> >> What are your plans for your patchset[2] ?
>> >> >> >
>> >> >> >Sorry, I was OOO for two weeks and then got distracted by some
>> >> >> >internal work :- ( I'll probably post another respin next week.
>> >> >> >I think I've addressed most of the Maciej's feedback, but the
>> >> >> >only thing that we need to move this forward is to support
>> >> >> >another device besides mlx5. Maciej was suggesting ice, but I
>> >> >> >don't have the hw :-( I have some idfp-capable devices, so I'll
>> >> >> >probably try to play with it instead (but
>> >> >the idpf driver is still not pulled).
>> >> >> >
>> >> >> >So if you want to help speed it up, we should probably focus
>> >> >> >first on getting some of the intel nics support tx metadata.
>> >> >> >To proceed, maybe I should post my next iteration and we can
>> >> >> >collaborate on the ice driver changes?
>> >> >> >Who should I CC explicitly?
>> >> >> >
>> >> >> Hi Stanislav,
>> >> >>
>> >> >> I can help to speed it up. I don't have ice HW on my hand as
>> >> >> well, so maybe we can start with igc drivers, followed by stmmac drivers.
>> >> >>
>> >> >> Please post your next iteration, then we can collaborate based on that.
>> >> >
>> >> >Awesome, thanks! The v2 is out, you're on the CC. Feel free to
>> >> >reach out directly if you have any questions or suggestions.
>> >>
>> >> Hi Stanislav,
>> >>
>> >> Thanks for the v2. I do have one question. What is the code base
>> >> which you are
>> >using?
>> >> When I try to apply your v2 patch set on top of latest net-next,
>> >> there are few merge conflicts, and it seem like Rx Metadata is not
>> >> included in your
>> >base.
>> >
>> >Anything prior to my recent commit "bpf: make it easier to add new
>> >metadata kfunc" should work. That's most likely the reason it conflicts.
>> >So try to cherry pick it on top of the following and let me know if
>> >you still have an issue; I can rebase and repost:
>> >5c04433daf9e - bpf: Charge modmem for struct_ops trampoline (6 days
>> >ago) <Song Liu>
>>
>> This base work for me. Thanks.
>> Btw, how we should collaborate?
>> After done coding and testing on my side, I send you my patches, then
>> you will include them into your patchset v3?
>
>Yeah, that works for me. Unless you have better ideas :-)

Great. Hopefully I am able to complete the first draft and send you 
something by next week.
 
>
>> >Regarding rx metadata: it's separate from af_xdp and it's more
>> >generically implemented in the xdp layer, see:
>> >Documentation/networking/xdp-rx-metadata.rst
>> >
>> >Also see tools/testing/selftests/bpf/prog_tests/xdp_metadata.c for an
>> >example on how to use both rx and tx sides.
>> >
>> >> Thanks & Regards
>> >> Siang
>> >>
>> >> >
>> >> >I also have to abaon my idea of playing with idpf since the driver
>> >> >that's posted on the list doesn't have af_xdp support :-(
>> >> >
>> >> >
>> >> >> Thanks & Regards
>> >> >> Siang
>> >> >>
>> >> >> >> My suggestion (to Intel) is that we implement the
>> >> >> >> TX-timestamp (plus
>> >> >> >> LaunchTime) on top of Stanslav's patches[2].  For drivers
>> >> >> >> igc+igb+stmmac which I think will cover the tests[3] need by
>> >> >> >> Arun/Costin (?). And then post it upstream for review.
>> >> >> >>
>> >> >> >> The Intel test tool[3] isn't open, but it is an AF_XDP based
>> >> >> >> Real-Time Compute Performance (RTCP) application that
>> >> >> >> show-case a real-time control loop application.  The current
>> >> >> >> code uses out-of-tree[4]
>> >> >"TXTIME"
>> >> >> >> LaunchTime feature, that want not upstreamed.
>> >> >> >>
>> >> >> >> Lets us instead implement a proper TX LaunchTime feature on top of
>[2].
>> >> >> >>
>> >> >> >> --Jesper
>> >> >> >> cc. XDP-hints ML as anyone is free to code this up, code help
>> >> >> >> here[5]
>> >> >> >>
>> >> >> >>
>> >> >> >> [1] https://eci.intel.com/
>> >> >> >> [2]
>> >> >> >> https://lore.kernel.org/all/20230809165418.2831456-1-sdf@google.
>> >> >> >> com / [3] https://github.com/OTCShare2/rtcp-xdp
>> >> >> >> [4]
>> >> >> >> https://lore.kernel.org/all/20210621230635.3a83851c@carbon/
>> >> >> >> [5]
>> >> >> >> https://github.com/xdp-project/xdp-project/blob/master/areas/
>> >> >> >> tsn
>> >> >> >> /co
>> >> >> >> de0
>> >> >> >> 1_follow_qdisc_TSN_offload.org#tx-time-to-hardware-driver-igc