All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Or Gerlitz <ogerlitz@mellanox.com>,
	John Fastabend <john.fastabend@gmail.com>
Cc: amir@vadai.me, jiri@resnulli.us, jeffrey.t.kirsher@intel.com,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [net-next PATCH 0/7] tc offload for cls_u32 on ixgbe
Date: Wed, 3 Feb 2016 07:21:29 -0500	[thread overview]
Message-ID: <56B1F0C9.3020802@mojatatu.com> (raw)
In-Reply-To: <56B1D713.3080803@mellanox.com>

On 16-02-03 05:31 AM, Or Gerlitz wrote:
> On 2/3/2016 12:21 PM, John Fastabend wrote:
>> Thanks, we will need at least a v2 to fixup some build errors
>> with various compile flags caught by build_bot and missed by me.
> Hi John,
>
> You didn't mark that as RFC... but we said this direction/approach yet
> to be talked @ netdev next-week, so.. can you clarify?
>
> I suggest not to rush and asking pulling this, lets have the tc workshop
> beforehand...
>

Yes, the tc workshop is a good place for this.
I think we can spill some of it into the switchdev workshop (which is a
nice flow since that happens later).

Some comments:
1) "priorities" for filters and some form of "index" for actions is
is needed. I think index (which tends to be a 32 bit value is what
Amir's patches refered to as "cookie" - or at least some hardware
can be used to query the action with). Priorities maybe implicit in
the order in which they are added. And the idea of appending vs
exclusivity vs replace (which  netlink already supports)
is important to worry about (TCAMS tend to assume an append mode
for example).

2) I like the u32 approach where it makes sense; but sometimes it
doesnt make sense from a usability pov. I work with some ASICs
that have 10 tuples that are  fixed. Yes, a user can describe a policy
with u32 but flower would be more  usable say with flower (both
programmatic and cli)

3) The concept of "hook address" is important to be able to express.
Amir's patches seemed to miss that (and John brought it up in an
email). It could be as simple as ifindex + hookid. With ifindex of
0 meaning all ports and maybe hookid of 0 meaning all hooks.
Hook semantics are as mentioned by John (as it stands right now
in/egress)

4) Why are we forsaking switchdev John?
This is certainly re-usable beyond NICs and SRIOV.

5)What happened to being both able to hardware and/or software?

Anyways, I think Seville would be a blast! Come one, come all.

cheers,
jamal

  reply	other threads:[~2016-02-03 12:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03  9:27 [net-next PATCH 0/7] tc offload for cls_u32 on ixgbe John Fastabend
2016-02-03  9:27 ` [net-next PATCH 1/7] net: rework ndo tc op to consume additional qdisc handle parameter John Fastabend
2016-02-03  9:58   ` kbuild test robot
2016-02-03  9:59   ` kbuild test robot
2016-02-03 11:44   ` kbuild test robot
2016-02-03  9:28 ` [net-next PATCH 2/7] net: rework setup_tc ndo op to consume general tc operand John Fastabend
2016-02-03  9:28 ` [net-next PATCH 3/7] net: sched: add cls_u32 offload hooks for netdevs John Fastabend
2016-02-03 10:14   ` kbuild test robot
2016-02-04 13:18   ` Amir Vadai"
2016-02-09 11:09     ` Fastabend, John R
2016-02-03  9:28 ` [net-next PATCH 4/7] net: add tc offload feature flag John Fastabend
2016-02-03  9:29 ` [net-next PATCH 5/7] net: tc: helper functions to query action types John Fastabend
2016-02-03  9:29 ` [net-next PATCH 6/7] net: ixgbe: add minimal parser details for ixgbe John Fastabend
2016-02-03  9:29 ` [net-next PATCH 7/7] net: ixgbe: add support for tc_u32 offload John Fastabend
2016-02-03 10:07   ` Amir Vadai"
2016-02-03 10:26     ` John Fastabend
2016-02-03 12:46       ` Jamal Hadi Salim
2016-02-03 19:02         ` Fastabend, John R
2016-02-09 11:30         ` Fastabend, John R
2016-02-04  7:30   ` Amir Vadai"
2016-02-04  8:23     ` Fastabend, John R
2016-02-04 12:12       ` Amir Vadai"
2016-02-09 11:27         ` Fastabend, John R
2016-02-03 10:11 ` [net-next PATCH 0/7] tc offload for cls_u32 on ixgbe Amir Vadai"
2016-02-03 10:21   ` John Fastabend
2016-02-03 10:31     ` Or Gerlitz
2016-02-03 12:21       ` Jamal Hadi Salim [this message]
2016-02-03 18:48         ` Fastabend, John R
2016-02-04 13:12           ` Jamal Hadi Salim
2016-02-09 11:24             ` Fastabend, John R
2016-02-09 12:20               ` Jamal Hadi Salim
2016-02-04  9:16 ` Jiri Pirko
2016-02-04 23:19   ` Pablo Neira Ayuso
2016-02-09 11:06     ` Fastabend, John R

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=56B1F0C9.3020802@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=amir@vadai.me \
    --cc=davem@davemloft.net \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jiri@resnulli.us \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.