From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Simon Horman <simon.horman@netronome.com>,
Daniel Borkmann <daniel@iogearbox.net>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
xiyou.wangcong@gmail.com, alexei.starovoitov@gmail.com,
john.fastabend@gmail.com, dj@verizon.com
Subject: Re: [net-next PATCH v2 1/5] introduce IFE action
Date: Wed, 24 Feb 2016 07:39:25 -0500 [thread overview]
Message-ID: <56CDA47D.30907@mojatatu.com> (raw)
In-Reply-To: <20160224054557.GA12134@vergenet.net>
On 16-02-24 12:46 AM, Simon Horman wrote:
> On Tue, Feb 23, 2016 at 05:12:34PM +0100, Daniel Borkmann wrote:
> From my point of view the test should be weather the encapsulation might
> reasonably be expected to be used outside of the context of tc. If so then
> it makes sense to use a netdev to allow sharing of infrastructure between
> different kernel components.
>
> I suspect the answer to that question is no and thus IMHO a netdev would be
> nice to have rather than compelling.
>
> With regards to overhead of netdevs: I think that could be mitigated to
> some extent by using LWT or some other metadata-based approach to allow a
> single netdev to be use by multiple tc action instances.
We actually have a use case where we offload this thing into
an embedded NIC.
In any case it doesnt make much sense to use a netdev for reasons i
specified. Just like it doesnt make sense when i want a policy which
pushes or pops vlans or vxlans to use netdevs either.
Yes it quacks like a duck(i.e has receive) and walks like a duck(has
stats) but it looks like an ostrich;->
cheers,
jamal
next prev parent reply other threads:[~2016-02-24 12:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 12:49 [net-next PATCH v2 0/5] net_sched: Add support for IFE action Jamal Hadi Salim
2016-02-23 12:49 ` [net-next PATCH v2 1/5] introduce " Jamal Hadi Salim
2016-02-23 13:32 ` Daniel Borkmann
2016-02-23 14:39 ` Jamal Hadi Salim
2016-02-23 16:12 ` Daniel Borkmann
2016-02-23 21:31 ` Cong Wang
2016-02-24 5:46 ` Simon Horman
2016-02-24 12:39 ` Jamal Hadi Salim [this message]
2016-02-24 12:52 ` Jamal Hadi Salim
2016-02-23 21:44 ` Cong Wang
2016-02-24 13:09 ` Jamal Hadi Salim
2016-02-24 17:39 ` Cong Wang
2016-02-24 17:37 ` Daniel Borkmann
2016-02-25 12:20 ` Jamal Hadi Salim
2016-02-25 21:46 ` Daniel Borkmann
2016-02-25 22:07 ` John Fastabend
2016-02-25 22:46 ` Jamal Hadi Salim
2016-02-23 12:49 ` [net-next PATCH v2 2/5] Support to encoding decoding skb mark on " Jamal Hadi Salim
2016-02-23 12:49 ` [net-next PATCH v2 3/5] Support to encoding decoding skb prio " Jamal Hadi Salim
2016-02-23 12:49 ` [net-next PATCH v2 4/5] Support to encoding decoding skb hashid " Jamal Hadi Salim
2016-02-23 12:49 ` [net-next PATCH v2 5/5] Support to encoding decoding skb queue map " 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=56CDA47D.30907@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dj@verizon.com \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=simon.horman@netronome.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 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.