[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190505.214940.508124612041892831.davem@davemloft.net>
Date: Sun, 05 May 2019 21:49:40 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jakub.kicinski@...ronome.com
Cc: netdev@...r.kernel.org, oss-drivers@...ronome.com,
jiri@...nulli.us, xiyou.wangcong@...il.com, idosch@...lanox.com,
f.fainelli@...il.com, andrew@...n.ch, vivien.didelot@...il.com,
gerlitz.or@...il.com, simon.horman@...ronome.com
Subject: Re: [PATCH net-next 00/13] net: act_police offload support
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Sat, 4 May 2019 04:46:15 -0700
> this set starts by converting cls_matchall to the new flow offload
> infrastructure. It so happens that all drivers implementing cls_matchall
> offload today also offload cls_flower, so its a little easier for
> them to handle the actions in unified flow_rule format, even though
> in cls_matchall there is no flow to speak of. If a driver ever appears
> which would prefer the old, direct access to TC exts, we can add the
> pointer in the offload structure back and support both.
>
> Next the act_police is added to actions supported by flow offload API.
>
> NFP support for act_police offload is added as the final step. The flower
> firmware is configured to perform TX rate limiting in a way which matches
> act_police's behaviour. It does not use DMA.IN back pressure, and
> instead drops packets after they had been already DMAed into the NIC.
> IOW it uses our standard traffic policing implementation, future patches
> will extend it to other ports and traffic directions.
Series applied.
Powered by blists - more mailing lists