On Wed, Apr 25, 2018 at 10:13 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: > On Wed, Apr 25, 2018 at 12:02 PM, John Hurley <john.hur...@netronome.com> > wrote: >> On Wed, Apr 25, 2018 at 9:56 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: >>> On Wed, Apr 25, 2018 at 11:51 AM, John Hurley <john.hur...@netronome.com> >>> wrote: >>>> On Wed, Apr 25, 2018 at 7:31 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: >>>>> On Wed, Apr 25, 2018 at 7:17 AM, Jakub Kicinski >>>>> <jakub.kicin...@netronome.com> wrote: >>>>>> From: John Hurley <john.hur...@netronome.com> >>>>>> >>>>>> When multiple netdevs are attached to a tc offload block and register for >>>>>> callbacks, a rule added to the block will be propogated to all netdevs. >>>>>> Previously these were detected as duplicates (based on cookie) and >>>>>> rejected. Modify the rule nfp lookup function to optionally include an >>>>>> ingress netdev and a host context along with the cookie value when >>>>>> searching for a rule. When a new rule is passed to the driver, the netdev >>>>>> the rule is to be attached to is considered when searching for >>>>>> dublicates. >>>>> >>>>> so if the same rule (cookie) is provided to the driver through multiple >>>>> ingress >>>>> devices you will not reject it -- what is the use case for that, is it >>>>> block sharing? >>>> >>>> Hi Or, >>>> Yes, block sharing is the current use-case. >>>> Simple example for clarity.... >>>> Here we want to offload the filter to both ingress devs nfp_0 and nfp_1: >>>> >>>> tc qdisc add dev nfp_p0 ingress_block 22 ingress >>>> tc qdisc add dev nfp_p1 ingress_block 22 ingress >>>> tc filter add block 22 protocol ip parent ffff: flower skip_sw >>>> ip_proto tcp action drop >>> >>> cool! >>> >>> Just out of curiosity, do you actually share this HW rule or you duplicate >>> it? >> >> It's duplicated. At HW level the ingress port is part of the match so >> technically it's >> a different rule. > > I see, we have also a match on the ingress port as part of the HW API, which > means we will have to apply a similar practice if we want to support > block sharing quickly. > > Just to make sure, under tc block sharing the tc stack calls for hw > offloading of the > same rule (same cookie) multiple times, each with different ingress > device, right? > > > Or.
So in the example above, when each qdisc add is called, a callback will be registered to the block. For each callback, the dev used is passed as priv data (presumably you do similar). When the filter is added, the block code triggers all callbacks with the same rule data [1]. We differentiate the callbacks with the priv data (ingress dev). [1] https://elixir.bootlin.com/linux/v4.17-rc2/source/net/sched/cls_api.c#L741
