> The first two patches do not provide new functionality for the user
> (except the logs are reworked). They are reworking to make the
> rxq scheduling and PMD auto load balance code more modular for cleanup
> and to be used by subsequent patches. They are also removing the code
> duplication between them by having some common functions they can both use.
> 
> The other patches are new functionality and unit tests.
> 
> github actions passing:
> https://github.com/kevintraynor/ovs/actions/runs/1011364932
> 

HI Kevin, thanks for the series. I've been testing the last few days and it 
looks good to me.

Can I ask you to rebase the series and send a new revision for application and 
merge?

With the overhead what has went in today there are a few conflicts.

Regards
Ian
> v5:
> - Rebased NEWS file update and added Acks. No code changes.
> 
> v4:
> - Fixed NEWS file conflict from (almost) mid-air collision of other patch 
> merging
> 
> v3:
> -  fixed asan enabled unit tests
> 
> v2:
> - added unit tests
> - rework from comments
> - much renaming and minor fixes
> - reordered the patches and added 2 more
> 
> ---
> 
> 1/7 reworks the current rxq scheduling code to make it more modular
> and reusable. No functional change.
> v3:
> - fixed asan enabled unit tests
> - minor comment syntax
> v2:
> - renamed functions on David's suggestions
> - used enum instead of bool for assignment type from the start
> - fixed mem leak
> - removed/simplified some redundant code
> 
> 2/7 makes PMD auto load balance reuse the common rxq scheduling code
> and removes the duplication of the rxq scheduling code in PMD auto load
> balance for making a dry run. No functional change.
> v3:
> - added missing clang annotation
> v2: minor changes
> 
> 3/7 new in v2. This is a small patch to make the pmd list used
> for rxq scheduling ordered by core id. This is just to add some consistency
> between schedules/test runs/pmd-cpu-mask changes.
> 
> 4/7 provides a fallback for if the user tries to pin an rxq to a PMD with
> pmd-rxq-affinity but the PMD is not in the pmd-cpu-mask. Previously it was
> not polled. Now it will be polled by an available core.
> v3:
> - minor comment syntax
> v2:
> - removed some unneeded code by David's suggestion here and in 1/7 of not
>   post-processing rxqs that have been already pinned
> 
> 5/7 adds a new option to assign rxqs to pmds that incorporates the
> estimated load of the PMD and removes the restriction for trying to
> equally distribute the number of rxqs across the PMDs. This means it
> is solely load based so will help optimize balancing the processing
> load across the PMDs. With this method, a group of low loaded rxqs
> may be on one PMD, while another PMD could have just one highly loaded
> rxq.
> v4/5:
> - fixed NEWS conflict
> v2:
> - combined the lowest_* functions on Sunil's suggestion
> - simplified some code
> - added unit tests
> 
> 6/7 adds an option to non-isolate the PMD when it is pinned with an rxq
> using pmd-rxq-affinity.
> v2:
> - added unit tests
> 
> 7/7 new in v2. There was no unit tests testing cross-numa assignments.
> i.e. what happens when there is no numa local pmds for an rxq. Aside
> from using the new logs, these tests are relevant regardless of this patchset.
> 
> Kevin Traynor (7):
>   dpif-netdev: Rework rxq scheduling code.
>   dpif-netdev: Make PMD auto load balance use common rxq scheduling.
>   dpif-netdev: Sort PMD list by core id for rxq scheduling.
>   dpif-netdev: Assign PMD for failed pinned rxqs.
>   dpif-netdev: Add group rxq scheduling assignment type.
>   dpif-netdev: Allow pin rxq and non-isolate PMD.
>   tests: Add new test for cross-numa pmd rxq assignments.
> 
>  Documentation/topics/dpdk/pmd.rst |   41 +-
>  NEWS                              |    5 +
>  lib/dpif-netdev.c                 | 1057 ++++++++++++++++++-----------
>  tests/pmd.at                      |  285 +++++++-
>  vswitchd/vswitch.xml              |   24 +-
>  5 files changed, 995 insertions(+), 417 deletions(-)
> 
> --
> 2.31.1
> 
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to