From: Jamal Hadi Salim <jhs@mojatatu•com>
To: "Fastabend, John R" <john.fastabend@gmail•com>,
Or Gerlitz <ogerlitz@mellanox•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: Tue, 9 Feb 2016 07:20:04 -0500 [thread overview]
Message-ID: <56B9D974.3000203@mojatatu.com> (raw)
In-Reply-To: <56B9CC6B.6050509@gmail.com>
On 16-02-09 06:24 AM, Fastabend, John R wrote:
> On 2/4/2016 5:12 AM, Jamal Hadi Salim wrote:
>>
>> On 16-02-03 01:48 PM, Fastabend, John R wrote:
>>
>> Basically most hardware (or i should say driver implementations of
>> mostly TCAMS) allow you to add exactly the same filter as many times
>> as you want. They dont really look at what you want to filter on
>> and then scream "conflict". IOW, you (user) are responsible for
>> conflict resolution at the filter level. The driver sees this blob
>> and requests for some index/key from the hardware then just adds it.
>> You can then use this key/index to delete/replace etc.
>> This is what i meant by "append" mode.
>> However if a classifier implementation cares about filter ambiguity
>> resolution, then priorities are used. We need to worry about the
>> bigger picture.
>>
>
> Sure in other classifiers its used but its not needed in the set I
> planned to added it later.
>
If you leave it open for some other hardware to use we should be fine.
>>
>>> For this series using cls_u32 the handle gives you everything you need
>>> to put entries in the right table and row. Namely the ht # and order #
>>> from 'tc'.
>>
>> True - but with a caveat. There are only 2^12 max tables you can
>> have for example and up to 2^12 filters per bucket etc.
>>
>
> This is a software limitation as well right? If it hasn't showed up
> as a limitation on the software side why would it be an issue here?
> Do you have more than 2^12 tables on your devices? If so I guess we
> can tack on another 32bits somewhere.
>
That handle is used as an "Address" to the 32 bit filter.
Just beware of the semantics the handle has.
It hasnt shown up as a software limitation because the defaults
are good enough for most people. But if you ever want to install
a million rules that can be looked up at a reasonable pps rate
it will become very obvious quickly. I have a sample setup in the
talk tommorow which shows such an example.
>> I think you need to take the u32 address and map it to something in your
>> hardware. But at the same time it is important to have the abstraction
>> closely emulate your hardware.
>>
>
> IMO the hardware/interface must preserve the same ordering of
> filters/hash_Tables/etc. How it does that mapping should be
> a driver concern and it can always abort if it fails.
>
Sure.
>>> Also ran a few tests and can't see how priority works in u32 maybe you
>>> can shed some light but as best I can tell it doesn't have any effect
>>> on rule execution.
>>>
>>
>> True.
>> u32 doesnt care because it will give you a nodeid if you dont specify
>> one. i.e conflict resolution is mapped to you not specifying exactly
>> the same ht:bkt:nodeid more than once. And if you will let the
>> kernel do it for you (as i am assumming you are saying your hardware
>> will) then no need.
>
> Yep. Faithfully offloading u32 here not changing anything except
> I do have to abort on some cases with the simpler devices. fm10k for
> example can model hash nodes with divisors > 1.
>
I wonder if when we get to capabilities we can do this...
>>
>
> My issue is we can map flower onto u32 that is fine and u32 onto
> bpf. But we lose a lot of the power of each classifier when we
> do this. flower for example is nice because of its simplicity
> presumably this translates into faster updates, u32 is great because
> we get full parse graph support and hash tables, ebpf is the biggest
> beast of all and lets us load arbitrary functions into the device.
> All are nice in their own right.
>
Did i send you my slides? ;->
cheers,
jamal
next prev parent reply other threads:[~2016-02-09 12:20 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
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 [this message]
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=56B9D974.3000203@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=amir@vadai$(echo .)me \
--cc=davem@davemloft$(echo .)net \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=ogerlitz@mellanox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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