From: Jamal Hadi Salim <jhs@mojatatu•com>
To: John Fastabend <john.fastabend@gmail•com>,
jiri@resnulli•us, daniel@iogearbox•net
Cc: netdev@vger•kernel.org, alexei.starovoitov@gmail•com,
davem@davemloft•net
Subject: Re: [net-next PATCH 3/4] net: sched: cls_u32 add bit to specify software only rules
Date: Wed, 24 Feb 2016 08:31:28 -0500 [thread overview]
Message-ID: <56CDB0B0.4080609@mojatatu.com> (raw)
In-Reply-To: <20160223190321.5970.58924.stgit@john-Precision-Tower-5810>
On 16-02-23 02:03 PM, John Fastabend wrote:
> In the initial implementation the only way to stop a rule from being
> inserted into the hardware table was via the device feature flag.
> However this doesn't work well when working on an end host system
> where packets are expect to hit both the hardware and software
> datapaths.
>
> For example we can imagine a rule that will match an IP address and
> increment a field. If we install this rule in both hardware and
> software we may increment the field twice. To date we have only
> added support for the drop action so we have been able to ignore
> these cases. But as we extend the action support we will hit this
> example plus more such cases. Arguably these are not even corner
> cases in many working systems these cases will be common.
>
> To avoid forcing the driver to always abort (i.e. the above example)
> this patch adds a flag to add a rule in software only. A careful
> user can use this flag to build software and hardware datapaths
> that work together. One example we have found particularly useful
> is to use hardware resources to set the skb->mark on the skb when
> the match may be expensive to run in software but a mark lookup
> in a hash table is cheap. The idea here is hardware can do in one
> lookup what the u32 classifier may need to traverse multiple lists
> and hash tables to compute. The flag is only passed down on inserts
> on deletion to avoid stale references in hardware we always try
> to remove a rule if it exists.
>
> Notice we do not add a hardware only case here. If you were to
> add a hardware only case then you are stuck with the problem
> of where to stick the software representation of that filter
> rule. If its stuck on the same filter list as the software only and
> software/hardware rules it then has to be walked over and ignored
> in the classify path. The overhead is not huge but is measurable.
> And with so much work being invested in speeding up rx/tx of
> pkt processing this is unacceptable IMO. The other option is to
> have a special hook just for hardware only resources. This is
> implemented in the next patch.
>
Dont have much time to look closely - will do later. Just wanted
to quip:
Would it make sense to have a user flag which says, "please store
this in s/ware - dont use it in s/ware just install it in h/ware."
This should be totally optional policy, but would help find the rules
faster from a control plane if i look for them in s/ware first.
There's some really freaking slow hardware interfaces out there...
(a record of 60 seconds to find something is not unheard of).
cheers,
jamal
next prev parent reply other threads:[~2016-02-24 13:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 19:02 [net-next PATCH 1/4] net: sched: consolidate offload decision in cls_u32 John Fastabend
2016-02-23 19:02 ` [net-next PATCH 2/4] net: cls_u32: move TC offload feature bit into cls_u32 offload logic John Fastabend
2016-02-24 6:12 ` Simon Horman
2016-02-24 13:21 ` Jamal Hadi Salim
2016-02-23 19:03 ` [net-next PATCH 3/4] net: sched: cls_u32 add bit to specify software only rules John Fastabend
2016-02-23 22:29 ` Samudrala, Sridhar
2016-02-23 23:30 ` John Fastabend
2016-02-24 6:11 ` Simon Horman
2016-02-24 7:24 ` John Fastabend
2016-02-24 8:04 ` Amir Vadai"
2016-02-24 8:40 ` Jiri Pirko
2016-02-24 8:55 ` John Fastabend
2016-02-24 9:29 ` Jiri Benc
2016-02-25 4:09 ` John Fastabend
2016-02-25 13:19 ` Jamal Hadi Salim
2016-02-25 16:39 ` John Fastabend
2016-02-24 13:31 ` Jamal Hadi Salim [this message]
2016-02-25 4:04 ` John Fastabend
2016-02-25 12:56 ` Jamal Hadi Salim
2016-02-25 21:56 ` John Fastabend
2016-02-25 23:05 ` Jamal Hadi Salim
2016-02-25 23:08 ` John Fastabend
2016-02-23 19:03 ` [net-next PATCH 4/4] net: sched: create hardware only classifier filter John Fastabend
2016-02-24 8:47 ` Jiri Pirko
2016-02-25 13:14 ` Jamal Hadi Salim
2016-02-25 17:36 ` John Fastabend
2016-02-24 6:12 ` [net-next PATCH 1/4] net: sched: consolidate offload decision in cls_u32 Simon Horman
2016-02-24 8:49 ` Jiri Pirko
2016-02-24 13:20 ` 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=56CDB0B0.4080609@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/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