On Fri, 2019-08-02 at 12:44 -0700, Alexei Starovoitov wrote: > On Fri, Aug 02, 2019 at 07:22:21PM +0000, Saeed Mahameed wrote: > > On Fri, 2019-08-02 at 10:37 -0700, Alexei Starovoitov wrote: > > > On Thu, Aug 1, 2019 at 6:30 PM Saeed Mahameed < > > > sae...@mellanox.com> > > > wrote: > > > > From: Eli Cohen <e...@mellanox.com> > > > > > > > > Use the scheduling elements to implement ingress rate limiter > > > > on an > > > > eswitch ports ingress traffic. Since the ingress of eswitch > > > > port is > > > > the > > > > egress of VF port, we control eswitch ingress by controlling VF > > > > egress. > > > > > > Looks like the patch is only passing args to firmware which is > > > doing > > > the magic. > > > Can you please describe what is the algorithm there? > > > Is it configurable? > > > > Hi Alexei, > > > > I am not sure how much details you are looking for, but let me > > share > > some of what i know: > > > > From a previous submission for legacy mode sriov vf bw limit, where > > we > > introduced the FW configuration API and the legacy sriov use case: > > https://patchwork.kernel.org/patch/9404655/ > > > > So basically the algorithm is Deficit Weighted Round Robin (DWRR) > > between the agents, we can control BW allocation/weight of each > > agent > > (vf vport). > > commit log of this patch says nothing about DWRR.
it says it uses the "scheduling elements ingress rate limiter" which automatically translates to DWRR, this is basic knowledge for mlx5 developers, and it is clear in the commit message when the FW API was introduced. > It is also not using any of the api that were provided by that > earlier patch. It is using the api: mlx5e_tc_configure_matchall => apply_police_params => mlx5_esw_modify_vport_rate => mlx5_modify_scheduling_element_cmd().. > what is going on? > can you please clarify what is bothering you ? we can fix it if necessary. Thanks, Saeed.
