public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Edward Cree <ecree@solarflare.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>, David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Michael Chan <michael.chan@broadcom.com>,
	Vishal Kulkarni <vishal@chelsio.com>
Subject: Re: [RFC PATCH v2 net-next 0/3] flow_offload: Re-add per-action statistics
Date: Mon, 20 May 2019 17:44:09 +0200	[thread overview]
Message-ID: <20190520154409.v6viswe47fltv652@salvia> (raw)
In-Reply-To: <7cdc59fd-e90f-6ff2-f429-257c8844be26@solarflare.com>

On Mon, May 20, 2019 at 04:37:10PM +0100, Edward Cree wrote:
> On 19/05/2019 01:22, Pablo Neira Ayuso wrote:
> > On Fri, May 17, 2019 at 04:27:29PM +0100, Edward Cree wrote:
> >> On 15/05/2019 20:39, Edward Cree wrote:
> > [...]
> >> Pablo, how do the two options interact with your netfilter offload?  I'm
> >>  guessing it's easier for you to find a unique pointer than to generate
> >>  a unique u32 action_index for each action.  I'm also assuming that
> >>  netfilter doesn't have a notion of shared actions.
> > It has that shared actions concept, see:
> >
> > https://netfilter.org/projects/nfacct/
> >
> > Have a look at 'nfacct' in iptables-extensions(8) manpage.
>
> Thanks.  Looking at net/netfilter/nfnetlink_acct.c, it looks as though you
>  don't have a u32 index in there; for the cookie approach, would the
>  address of the struct nf_acct (casted to unsigned long) work to uniquely
>  identify actions that should be shared?
> I'm not 100% sure how nf (or nfacct) offload is going to look, so I might
>  be barking up the wrong tree here.  But it seems like the cookie method
>  should work better for you — even if you did have an index, how would you
>  avoid collisions with TC actions using the same indices if both are in
>  use on a box?  Cookies OTOH are pointers, so guaranteed unique :)

The cookie approach per-action looks fine to me, there's already a
cookie to identify the rule, so this looks natural to me.

  parent reply	other threads:[~2019-05-20 15:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 19:39 [RFC PATCH v2 net-next 0/3] flow_offload: Re-add per-action statistics Edward Cree
2019-05-15 19:42 ` [RFC PATCH v2 net-next 1/3] flow_offload: copy tcfa_index into flow_action_entry Edward Cree
2019-05-18 20:30   ` Jamal Hadi Salim
2019-05-15 19:42 ` [RFC PATCH v2 net-next 2/3] flow_offload: restore ability to collect separate stats per action Edward Cree
2019-05-18 20:35   ` Jamal Hadi Salim
2019-05-20 15:46     ` Edward Cree
2019-05-20 15:55       ` Jamal Hadi Salim
2019-05-15 19:42 ` [RFC PATCH v2 net-next 3/3] flow_offload: include linux/kernel.h from flow_offload.h Edward Cree
2019-05-17 15:27 ` [RFC PATCH v2 net-next 0/3] flow_offload: Re-add per-action statistics Edward Cree
2019-05-17 17:14   ` Edward Cree
2019-05-18 20:39     ` Jamal Hadi Salim
2019-05-20 15:26       ` Edward Cree
2019-05-20 15:38         ` Jamal Hadi Salim
2019-05-20 16:10           ` Edward Cree
2019-05-20 16:29             ` Jamal Hadi Salim
2019-05-20 16:32               ` Jamal Hadi Salim
2019-05-20 17:58               ` Edward Cree
2019-05-20 18:36               ` Edward Cree
2019-05-20 21:12                 ` Jamal Hadi Salim
2019-05-21 12:46                   ` Jamal Hadi Salim
2019-05-21 13:23                     ` Vlad Buslov
2019-05-22 15:08                       ` Vlad Buslov
2019-05-22 15:13                         ` [RFC PATCH net-next] net: sched: don't use tc_action->order during action dump Vlad Buslov
2019-05-22 17:24                         ` [RFC PATCH v2 net-next 0/3] flow_offload: Re-add per-action statistics Jamal Hadi Salim
2019-05-22 17:49                           ` Vlad Buslov
2019-05-22 18:23                             ` Jamal Hadi Salim
2019-05-22 18:26                               ` Jamal Hadi Salim
2019-05-19  0:22   ` Pablo Neira Ayuso
2019-05-20 15:37     ` Edward Cree
2019-05-20 15:40       ` Jamal Hadi Salim
2019-05-20 15:44       ` Pablo Neira Ayuso [this message]
2019-05-18 20:30 ` Jamal Hadi Salim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190520154409.v6viswe47fltv652@salvia \
    --to=pablo@netfilter.org \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=ecree@solarflare.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=vishal@chelsio.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox