netdev - RE: [PATCH/RFC net-next] tc: allow drivers to accept gact with PIPE when offloading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <PH0PR13MB4793C795A4446BA2E4DE000E94129@PH0PR13MB4793.namprd13.prod.outlook.com>
Date:   Tue, 29 Nov 2022 07:32:10 +0000
From:   Tianyu Yuan <tianyu.yuan@...igine.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
CC:     Simon Horman <simon.horman@...igine.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Davide Caratti <dcaratti@...hat.com>,
        Edward Cree <edward.cree@....com>,
        Eelco Chaudron <echaudro@...hat.com>,
        Ilya Maximets <i.maximets@....org>,
        Marcelo Leitner <mleitner@...hat.com>,
        Oz Shlomo <ozsh@...dia.com>, Paul Blakey <paulb@...dia.com>,
        Vlad Buslov <vladbu@...dia.com>,
        "dev@...nvswitch.org" <dev@...nvswitch.org>,
        oss-drivers <oss-drivers@...igine.com>,
        Ziyang Chen <ziyang.chen@...igine.com>
Subject: RE: [PATCH/RFC net-next] tc: allow drivers to accept gact with PIPE
 when offloading


On Mon, Nov 28, 2022 at 7:36 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On Mon, Nov 28, 2022 at 3:56 AM Tianyu Yuan <tianyu.yuan@...igine.com>
> wrote:
> >
> > Hi Jamal,
> >
> >
> > When no action is specified, there should not be gact with PIPE, rather than
> a gact with drop, like:
> >

Thanks for reminding, I'll add that :)
> 
> Thanks for the example dumps. I think you should put them in your commit
> logs.
> 
> [..]
> 
> >
> > About the second scenario of PIPE alone, I don’t think it should exist.
> > Besides this adding a PIPE at the first place of a tc filter to update
> > the flow stats, another attempt that directly store the flower stats,
> > which is got from driver, in socket transacted with userspace (e.g.
> > OVS). In this approach, we don’t have to make changes in driver. Which
> > could be a better solution you think for this propose
> 
> I was thinking about a case of a filter with no actions but with interest in a
> counter for that match.
> 
> i.e pseudo-tc-dsl as:
> tc filter add ... flower blah action count
> 
> which translated is:
> tc filter add ... flower blah action pipe
> 
> cheers,
> jamal

I test the case that only add a gact pipe in a filter as a counter, the result is shown below:

# tc filter add dev eth5 parent ffff: pref 4 flower action gact pipe
# tc -s -d filter show dev eth5 ingress
filter parent ffff: protocol ip pref 4 flower chain 0
filter parent ffff: protocol ip pref 4 flower chain 0 handle 0x1
  eth_type ipv4
  in_hw in_hw_count 1
        action order 1: gact action pipe
         random type none pass val 0
         index 2 ref 1 bind 1 installed 314 sec used 0 sec
        Action statistics:
        Sent 8449056 bytes 5588 pkt (dropped 0, overlimits 0 requeues 0)
        Sent software 0 bytes 0 pkt
        Sent hardware 8449056 bytes 5588 pkt
        backlog 0b 0p requeues 0
        used_hw_stats delayed

in which eth5 is a vf representor and packets are coming from corresponding vf. Packets are
generated by iperf udp.
This pipe(counter) still shows in_hw flag, although the only one action is ignored by driver.

Best regards,
Tianyu