netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Paul Blakey <paulb@mellanox.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Jiri Pirko <jiri@mellanox.com>,
	Hadar Hen Zion <hadarh@mellanox.com>,
	Or Gerlitz <ogerlitz@mellanox.com>, Roi Dayan <roid@mellanox.com>,
	Roman Mashak <mrv@mojatatu.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
Date: Sun, 8 Jan 2017 18:15:26 +0100	[thread overview]
Message-ID: <20170108171526.GG1971@nanopsycho> (raw)
In-Reply-To: <586A9A9F.4030002@gmail.com>

Mon, Jan 02, 2017 at 07:23:27PM CET, john.fastabend@gmail.com wrote:
>On 17-01-02 06:59 AM, Jamal Hadi Salim wrote:
>> 
>> We have been using a cookie as well for actions (which we have been
>> using but have been too lazy to submit so far). I am going to port
>> it over to the newer kernels and post it.
>> In our case that is intended to be opaque to the kernel i.e kernel
>> never inteprets it; in that case it is similar to the kernel
>> FIB protocol field.
>> 
>> In your case - could this cookie have been a class/flowid
>> (a 32 bit)?
>> And would it not make more sense for it the cookie to be
>> generic to all classifiers? i.e why is it specific to flower?
>> 
>> cheers,
>> jamal
>> 
>> On 17-01-02 08:13 AM, Paul Blakey wrote:
>>> This is to support saving extra data that might be helpful on retrieval.
>>> First use case is upcoming openvswitch flow offloads, extra data will
>>> include UFID and port mappings for each added flow.
>>>
>>> Signed-off-by: Paul Blakey <paulb@mellanox.com>
>>> Reviewed-by: Roi Dayan <roid@mellanox.com>
>>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>>> ---
>
>Additionally I would like to point out this is an arbitrary length binary
>blob (for undefined use, without even a specified encoding) that gets pushed
>between user space and hardware ;) This seemed to get folks fairly excited in
>the past.

No John, this is very different. What was frowned upon was interchange
of binary blobs between userspace and hw. In this case, cookie is never
interpreted, only stored in kernel memory, used *always* only by user.

  parent reply	other threads:[~2017-01-08 17:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-02 13:13 [PATCH net-next] net/sched: cls_flower: Add user specified data Paul Blakey
2017-01-02 14:59 ` Jamal Hadi Salim
2017-01-02 18:23   ` John Fastabend
2017-01-02 22:21     ` Jamal Hadi Salim
2017-01-02 22:58       ` John Fastabend
2017-01-03  1:22         ` Jamal Hadi Salim
2017-01-03  4:33           ` John Fastabend
2017-01-03 11:44             ` Jamal Hadi Salim
2017-01-03 12:22               ` Paul Blakey
2017-01-04 10:14                 ` Simon Horman
2017-01-04 11:45                   ` Paul Blakey
2017-01-05  8:03                     ` Simon Horman
2017-01-14 13:06                 ` Jamal Hadi Salim
2017-01-08 17:19       ` Jiri Pirko
2017-01-09 18:23         ` John Fastabend
2017-01-14 12:56           ` Jamal Hadi Salim
2017-01-14 14:48             ` Jiri Pirko
2017-01-14 15:03               ` Jamal Hadi Salim
2017-01-14 15:29                 ` Jiri Pirko
2017-01-14 17:46                   ` Jamal Hadi Salim
2017-01-08 17:15     ` Jiri Pirko [this message]
2017-01-08 17:12   ` Jiri Pirko
2017-01-15 17:36     ` Paul Blakey
2017-01-15 19:08       ` John Fastabend
2017-01-16  7:54         ` Paul Blakey
2017-01-16  9:51           ` Jiri Pirko
2017-01-17 11:23             ` Jamal Hadi Salim
2017-01-17 11:53               ` Paul Blakey
2017-01-18 11:06                 ` 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=20170108171526.GG1971@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=hadarh@mellanox.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@mellanox.com \
    --cc=john.fastabend@gmail.com \
    --cc=mrv@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=paulb@mellanox.com \
    --cc=roid@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).