| Message ID | 20230330112057.14242-1-simon.horman@corigine.com |
|---|---|
| Headers | show |
| Series | Add support for DPDK meter HW offload | expand |
Hi The usage of the proxy port is wrong. All transfer offload should be migrated to use it. There was [1-4], but it was not completed. Meters should be created only on the proxy ports. As all offloads are moved to use proxy ports, this is how they are shared. Since we don't know the proxy port when meter is added, it can be lazy created upon the first flow that uses this meter/proxy-port (referenced counted), and destroy upon the last flow destroy using it. As there might be multiple "proxy" ports, there might be multiple HW meter objects associated with the same SW one. This should be managed. [1] http://patchwork.ozlabs.org/project/openvswitch/list/?series=302525&state=* [2] http://patchwork.ozlabs.org/project/openvswitch/list/?series=310413&state=* [3] http://patchwork.ozlabs.org/project/openvswitch/list/?series=310415&state=* [4] http://patchwork.ozlabs.org/project/openvswitch/list/?series=342885&state=* Thanks, Eli >-----Original Message----- >From: Simon Horman <simon.horman@corigine.com> >Sent: Thursday, 30 March 2023 14:21 >To: dev@openvswitch.org >Cc: Ilya Maximets <i.maximets@ovn.org>; Eli Britstein <elibr@nvidia.com>; >Chaoyong He <chaoyong.he@corigine.com>; Peng Zhang ><peng.zhang@corigine.com>; Jin Liu <jin.liu@corigine.com>; oss- >drivers@corigine.com >Subject: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW offload > >External email: Use caution opening links or attachments > > >Hi, > >this series adds support for DPDK meter HW offload. > >Changes between v2 and v3. >* Use common API for DPDK and non-DPDK meter offloads >* Make use of netdev_ports_traverse to offload the meter >* Add dpdk-latest to subject prefix > >Changes between v1 and v2: >* Add the prox mechanism: add the meter by proxy id >* Change the offload interface from netdev-dpdk to the netdev-offload >* Changed base to dpdk-latest branch > >Peng Zhang (6): > netdev-offload-dpdk: use flow transfer proxy > netdev-offload: Let meter offload API can be used with DPDK > dpif-netdev: Offloading meter with DPDK > netdev-offload-dpdk: Implement meter offload API for DPDK > netdev-dpdk: add meter algorithms > netdev-dpdk-offload: Add support for meter action > > Documentation/howto/dpdk.rst | 5 +- > lib/dpif-netdev.c | 22 ++- > lib/netdev-dpdk.c | 306 +++++++++++++++++++++++++++++++++- > lib/netdev-dpdk.h | 43 +++++ > lib/netdev-offload-dpdk.c | 97 +++++++++++ > lib/netdev-offload-provider.h | 21 ++- > lib/netdev-offload-tc.c | 9 +- > lib/netdev-offload.c | 135 ++++++++++++++- > lib/netdev-offload.h | 9 + > 9 files changed, 633 insertions(+), 14 deletions(-) > >-- >2.30.2
Hi,
Thanks for your reply.
Our original idea is imitating OVS-TC, meter action and flow is independence. First through
the proxy port create the meter, then flow use meter with meter id. So I only add the proxy port,
doesn't revise the flow with proxy port. So you think this idea cant be accepted?
As your said, when the flow first time use the meter/proxy port, we offload the meter to the HW,
when the last flow with the meter/proxy port will be delete, we delete the meter from the HW.
About your idea, I have some issue about modify the flow, because the flow cant get the meter
status, so we can't through flow to modify the meter in the HW. We have two way to solve it, one is modify
the meter, we delete all the flow with meter from the HW, the key is through meter id lookup the all flow with
the meter id from the HW. Another is update the meter through the proxy port in the HW. Do you think which
is better?
B.R.
Peng
> -----Original Message-----
> From: Eli Britstein <elibr@nvidia.com>
> Sent: Thursday, March 30, 2023 8:34 PM
> To: Simon Horman <simon.horman@corigine.com>; dev@openvswitch.org
> Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He
> <chaoyong.he@corigine.com>; Nole Zhang <peng.zhang@corigine.com>;
> Kevin Liu <jin.liu@corigine.com>; oss-drivers <oss-drivers@corigine.com>
> Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW
> offload
>
> Hi
>
> The usage of the proxy port is wrong.
> All transfer offload should be migrated to use it. There was [1-4], but it was
> not completed.
>
> Meters should be created only on the proxy ports. As all offloads are moved
> to use proxy ports, this is how they are shared.
> Since we don't know the proxy port when meter is added, it can be lazy
> created upon the first flow that uses this meter/proxy-port (referenced
> counted), and destroy upon the last flow destroy using it.
> As there might be multiple "proxy" ports, there might be multiple HW meter
> objects associated with the same SW one. This should be managed.
>
> [1]
> http://patchwork.ozlabs.org/project/openvswitch/list/?series=302525&state
> =*
> [2]
> http://patchwork.ozlabs.org/project/openvswitch/list/?series=310413&state
> =*
> [3]
> http://patchwork.ozlabs.org/project/openvswitch/list/?series=310415&state
> =*
> [4]
> http://patchwork.ozlabs.org/project/openvswitch/list/?series=342885&state
> =*
>
> Thanks,
> Eli
>
> >-----Original Message-----
> >From: Simon Horman <simon.horman@corigine.com>
> >Sent: Thursday, 30 March 2023 14:21
> >To: dev@openvswitch.org
> >Cc: Ilya Maximets <i.maximets@ovn.org>; Eli Britstein
> ><elibr@nvidia.com>; Chaoyong He <chaoyong.he@corigine.com>; Peng
> Zhang
> ><peng.zhang@corigine.com>; Jin Liu <jin.liu@corigine.com>; oss-
> >drivers@corigine.com
> >Subject: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW
> >offload
> >
> >External email: Use caution opening links or attachments
> >
> >
> >Hi,
> >
> >this series adds support for DPDK meter HW offload.
> >
> >Changes between v2 and v3.
> >* Use common API for DPDK and non-DPDK meter offloads
> >* Make use of netdev_ports_traverse to offload the meter
> >* Add dpdk-latest to subject prefix
> >
> >Changes between v1 and v2:
> >* Add the prox mechanism: add the meter by proxy id
> >* Change the offload interface from netdev-dpdk to the netdev-offload
> >* Changed base to dpdk-latest branch
> >
> >Peng Zhang (6):
> > netdev-offload-dpdk: use flow transfer proxy
> > netdev-offload: Let meter offload API can be used with DPDK
> > dpif-netdev: Offloading meter with DPDK
> > netdev-offload-dpdk: Implement meter offload API for DPDK
> > netdev-dpdk: add meter algorithms
> > netdev-dpdk-offload: Add support for meter action
> >
> > Documentation/howto/dpdk.rst | 5 +-
> > lib/dpif-netdev.c | 22 ++-
> > lib/netdev-dpdk.c | 306 +++++++++++++++++++++++++++++++++-
> > lib/netdev-dpdk.h | 43 +++++
> > lib/netdev-offload-dpdk.c | 97 +++++++++++
> > lib/netdev-offload-provider.h | 21 ++-
> > lib/netdev-offload-tc.c | 9 +-
> > lib/netdev-offload.c | 135 ++++++++++++++-
> > lib/netdev-offload.h | 9 +
> > 9 files changed, 633 insertions(+), 14 deletions(-)
> >
> >--
> >2.30.2
Hi The kernel provides infrastructure that does not exist for DPDK. TC is different and cannot be imitated directly in all cases. Using a meter object created on one port (proxy) on another one (for flow) is illegal. Also, with this approach, even if fixed, offload will not work on if the port is added after the meter is created. Regarding modify, it should be on the fly. When a meter is updated, the related HW meters should be updated via their proxy ports (as the ones created them). If all flows using it are un-offloaded, they will not be re-offloaded. Thanks, Eli >-----Original Message----- >From: Nole Zhang <peng.zhang@corigine.com> >Sent: Friday, 31 March 2023 6:20 >To: Eli Britstein <elibr@nvidia.com>; Simon Horman ><simon.horman@corigine.com>; dev@openvswitch.org >Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He ><chaoyong.he@corigine.com>; Kevin Liu <jin.liu@corigine.com>; oss-drivers ><oss-drivers@corigine.com> >Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW >offload > >External email: Use caution opening links or attachments > > >Hi, > Thanks for your reply. > Our original idea is imitating OVS-TC, meter action and flow is >independence. First through the proxy port create the meter, then flow use >meter with meter id. So I only add the proxy port, doesn't revise the flow with >proxy port. So you think this idea cant be accepted? > As your said, when the flow first time use the meter/proxy port, we >offload the meter to the HW, when the last flow with the meter/proxy port >will be delete, we delete the meter from the HW. > About your idea, I have some issue about modify the flow, because the >flow cant get the meter status, so we can't through flow to modify the meter >in the HW. We have two way to solve it, one is modify the meter, we delete >all the flow with meter from the HW, the key is through meter id lookup the >all flow with the meter id from the HW. Another is update the meter through >the proxy port in the HW. Do you think which is better? >B.R. >Peng > >> -----Original Message----- >> From: Eli Britstein <elibr@nvidia.com> >> Sent: Thursday, March 30, 2023 8:34 PM >> To: Simon Horman <simon.horman@corigine.com>; dev@openvswitch.org >> Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He >> <chaoyong.he@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; >> Kevin Liu <jin.liu@corigine.com>; oss-drivers >> <oss-drivers@corigine.com> >> Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW >> offload >> >> Hi >> >> The usage of the proxy port is wrong. >> All transfer offload should be migrated to use it. There was [1-4], >> but it was not completed. >> >> Meters should be created only on the proxy ports. As all offloads are >> moved to use proxy ports, this is how they are shared. >> Since we don't know the proxy port when meter is added, it can be lazy >> created upon the first flow that uses this meter/proxy-port >> (referenced counted), and destroy upon the last flow destroy using it. >> As there might be multiple "proxy" ports, there might be multiple HW >> meter objects associated with the same SW one. This should be managed. >> >> [1] >> >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch >> >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D302525 >%26 >> >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108db >3196 >> >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638158295884302 >138%7 >> >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >TiI6Ik1 >> >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B1fCFn4UeTJpbVSr >m3Sh5KqA7% >> 2FG64u81oeBP9xLY0q8%3D&reserved=0 >> =* >> [2] >> >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch >> >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D310413 >%26 >> >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108db >3196 >> >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638158295884302 >138%7 >> >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >TiI6Ik1 >> >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nywcgXWj2VfgzYW5D >DgnJWm002r2 >> Jv03VDShjkToMiA%3D&reserved=0 >> =* >> [3] >> >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch >> >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D310415 >%26 >> >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108db >3196 >> >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638158295884302 >138%7 >> >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >TiI6Ik1 >> >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9Ee5Qz9yCwx%2BHcF6 >f%2BT3F8Oo >> NwZyYYcinT10wh7BG%2F0%3D&reserved=0 >> =* >> [4] >> >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch >> >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D342885 >%26 >> >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108db >3196 >> >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638158295884302 >138%7 >> >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >TiI6Ik1 >> >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rmW1%2FaUKHmj2Wd >nmHwcSIE7XZH >> 0pEjIOLvGoiCRF8KM%3D&reserved=0 >> =* >> >> Thanks, >> Eli >> >> >-----Original Message----- >> >From: Simon Horman <simon.horman@corigine.com> >> >Sent: Thursday, 30 March 2023 14:21 >> >To: dev@openvswitch.org >> >Cc: Ilya Maximets <i.maximets@ovn.org>; Eli Britstein >> ><elibr@nvidia.com>; Chaoyong He <chaoyong.he@corigine.com>; Peng >> Zhang >> ><peng.zhang@corigine.com>; Jin Liu <jin.liu@corigine.com>; oss- >> >drivers@corigine.com >> >Subject: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW >> >offload >> > >> >External email: Use caution opening links or attachments >> > >> > >> >Hi, >> > >> >this series adds support for DPDK meter HW offload. >> > >> >Changes between v2 and v3. >> >* Use common API for DPDK and non-DPDK meter offloads >> >* Make use of netdev_ports_traverse to offload the meter >> >* Add dpdk-latest to subject prefix >> > >> >Changes between v1 and v2: >> >* Add the prox mechanism: add the meter by proxy id >> >* Change the offload interface from netdev-dpdk to the netdev-offload >> >* Changed base to dpdk-latest branch >> > >> >Peng Zhang (6): >> > netdev-offload-dpdk: use flow transfer proxy >> > netdev-offload: Let meter offload API can be used with DPDK >> > dpif-netdev: Offloading meter with DPDK >> > netdev-offload-dpdk: Implement meter offload API for DPDK >> > netdev-dpdk: add meter algorithms >> > netdev-dpdk-offload: Add support for meter action >> > >> > Documentation/howto/dpdk.rst | 5 +- >> > lib/dpif-netdev.c | 22 ++- >> > lib/netdev-dpdk.c | 306 +++++++++++++++++++++++++++++++++- >> > lib/netdev-dpdk.h | 43 +++++ >> > lib/netdev-offload-dpdk.c | 97 +++++++++++ >> > lib/netdev-offload-provider.h | 21 ++- >> > lib/netdev-offload-tc.c | 9 +- >> > lib/netdev-offload.c | 135 ++++++++++++++- >> > lib/netdev-offload.h | 9 + >> > 9 files changed, 633 insertions(+), 14 deletions(-) >> > >> >-- >> >2.30.2
Hi, Ok, thanks for your reply. I will continue to work on it. B.R. Peng > -----Original Message----- > From: Eli Britstein <elibr@nvidia.com> > Sent: Sunday, April 2, 2023 1:58 PM > To: Nole Zhang <peng.zhang@corigine.com>; Simon Horman > <simon.horman@corigine.com>; dev@openvswitch.org > Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He > <chaoyong.he@corigine.com>; Kevin Liu <jin.liu@corigine.com>; oss-drivers > <oss-drivers@corigine.com> > Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW > offload > > Hi > > The kernel provides infrastructure that does not exist for DPDK. TC is > different and cannot be imitated directly in all cases. > Using a meter object created on one port (proxy) on another one (for flow) is > illegal. > Also, with this approach, even if fixed, offload will not work on if the port is > added after the meter is created. > Regarding modify, it should be on the fly. When a meter is updated, the > related HW meters should be updated via their proxy ports (as the ones > created them). > If all flows using it are un-offloaded, they will not be re-offloaded. > > Thanks, > Eli > > >-----Original Message----- > >From: Nole Zhang <peng.zhang@corigine.com> > >Sent: Friday, 31 March 2023 6:20 > >To: Eli Britstein <elibr@nvidia.com>; Simon Horman > ><simon.horman@corigine.com>; dev@openvswitch.org > >Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He > ><chaoyong.he@corigine.com>; Kevin Liu <jin.liu@corigine.com>; > >oss-drivers <oss-drivers@corigine.com> > >Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW > >offload > > > >External email: Use caution opening links or attachments > > > > > >Hi, > > Thanks for your reply. > > Our original idea is imitating OVS-TC, meter action and flow is > >independence. First through the proxy port create the meter, then flow > >use meter with meter id. So I only add the proxy port, doesn't revise > >the flow with proxy port. So you think this idea cant be accepted? > > As your said, when the flow first time use the meter/proxy > >port, we offload the meter to the HW, when the last flow with the > >meter/proxy port will be delete, we delete the meter from the HW. > > About your idea, I have some issue about modify the flow, > >because the flow cant get the meter status, so we can't through flow to > >modify the meter in the HW. We have two way to solve it, one is modify > >the meter, we delete all the flow with meter from the HW, the key is > >through meter id lookup the all flow with the meter id from the HW. > >Another is update the meter through the proxy port in the HW. Do you > think which is better? > >B.R. > >Peng > > > >> -----Original Message----- > >> From: Eli Britstein <elibr@nvidia.com> > >> Sent: Thursday, March 30, 2023 8:34 PM > >> To: Simon Horman <simon.horman@corigine.com>; > dev@openvswitch.org > >> Cc: Ilya Maximets <i.maximets@ovn.org>; Chaoyong He > >> <chaoyong.he@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; > >> Kevin Liu <jin.liu@corigine.com>; oss-drivers > >> <oss-drivers@corigine.com> > >> Subject: RE: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW > >> offload > >> > >> Hi > >> > >> The usage of the proxy port is wrong. > >> All transfer offload should be migrated to use it. There was [1-4], > >> but it was not completed. > >> > >> Meters should be created only on the proxy ports. As all offloads are > >> moved to use proxy ports, this is how they are shared. > >> Since we don't know the proxy port when meter is added, it can be > >> lazy created upon the first flow that uses this meter/proxy-port > >> (referenced counted), and destroy upon the last flow destroy using it. > >> As there might be multiple "proxy" ports, there might be multiple HW > >> meter objects associated with the same SW one. This should be managed. > >> > >> [1] > >> > >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc > h > >> > >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D30252 > 5 > >%26 > >> > >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108 > db > >3196 > >> > >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63815829588 > 4302 > >138%7 > >> > >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > B > >TiI6Ik1 > >> > >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B1fCFn4UeTJpbV > Sr > >m3Sh5KqA7% > >> 2FG64u81oeBP9xLY0q8%3D&reserved=0 > >> =* > >> [2] > >> > >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc > h > >> > >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D31041 > 3 > >%26 > >> > >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108 > db > >3196 > >> > >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63815829588 > 4302 > >138%7 > >> > >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > B > >TiI6Ik1 > >> > >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nywcgXWj2VfgzYW5 > D > >DgnJWm002r2 > >> Jv03VDShjkToMiA%3D&reserved=0 > >> =* > >> [3] > >> > >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc > h > >> > >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D31041 > 5 > >%26 > >> > >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108 > db > >3196 > >> > >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63815829588 > 4302 > >138%7 > >> > >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > B > >TiI6Ik1 > >> > >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9Ee5Qz9yCwx%2BHc > F6 > >f%2BT3F8Oo > >> NwZyYYcinT10wh7BG%2F0%3D&reserved=0 > >> =* > >> [4] > >> > >https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc > h > >> > >work.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fseries%3D34288 > 5 > >%26 > >> > >state&data=05%7C01%7Celibr%40nvidia.com%7C0f1851b0a5e94982778108 > db > >3196 > >> > >c6d8%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63815829588 > 4302 > >138%7 > >> > >CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > B > >TiI6Ik1 > >> > >haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rmW1%2FaUKHmj2 > Wd > >nmHwcSIE7XZH > >> 0pEjIOLvGoiCRF8KM%3D&reserved=0 > >> =* > >> > >> Thanks, > >> Eli > >> > >> >-----Original Message----- > >> >From: Simon Horman <simon.horman@corigine.com> > >> >Sent: Thursday, 30 March 2023 14:21 > >> >To: dev@openvswitch.org > >> >Cc: Ilya Maximets <i.maximets@ovn.org>; Eli Britstein > >> ><elibr@nvidia.com>; Chaoyong He <chaoyong.he@corigine.com>; Peng > >> Zhang > >> ><peng.zhang@corigine.com>; Jin Liu <jin.liu@corigine.com>; oss- > >> >drivers@corigine.com > >> >Subject: [PATCH dpdk-latest v3 0/6] Add support for DPDK meter HW > >> >offload > >> > > >> >External email: Use caution opening links or attachments > >> > > >> > > >> >Hi, > >> > > >> >this series adds support for DPDK meter HW offload. > >> > > >> >Changes between v2 and v3. > >> >* Use common API for DPDK and non-DPDK meter offloads > >> >* Make use of netdev_ports_traverse to offload the meter > >> >* Add dpdk-latest to subject prefix > >> > > >> >Changes between v1 and v2: > >> >* Add the prox mechanism: add the meter by proxy id > >> >* Change the offload interface from netdev-dpdk to the > >> >netdev-offload > >> >* Changed base to dpdk-latest branch > >> > > >> >Peng Zhang (6): > >> > netdev-offload-dpdk: use flow transfer proxy > >> > netdev-offload: Let meter offload API can be used with DPDK > >> > dpif-netdev: Offloading meter with DPDK > >> > netdev-offload-dpdk: Implement meter offload API for DPDK > >> > netdev-dpdk: add meter algorithms > >> > netdev-dpdk-offload: Add support for meter action > >> > > >> > Documentation/howto/dpdk.rst | 5 +- > >> > lib/dpif-netdev.c | 22 ++- > >> > lib/netdev-dpdk.c | 306 +++++++++++++++++++++++++++++++++- > >> > lib/netdev-dpdk.h | 43 +++++ > >> > lib/netdev-offload-dpdk.c | 97 +++++++++++ > >> > lib/netdev-offload-provider.h | 21 ++- > >> > lib/netdev-offload-tc.c | 9 +- > >> > lib/netdev-offload.c | 135 ++++++++++++++- > >> > lib/netdev-offload.h | 9 + > >> > 9 files changed, 633 insertions(+), 14 deletions(-) > >> > > >> >-- > >> >2.30.2