From: "Yang, Yi" <yi.y.yang@intel.com>
To: Jiri Benc <jbenc@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"dev@openvswitch.org" <dev@openvswitch.org>,
"e@erig.me" <e@erig.me>,
"davem@davemloft.net" <davem@davemloft.net>,
Pravin Shelar <pshelar@ovn.org>,
jan.scheurich@ericsson.com
Subject: Re: [PATCH net-next v9] openvswitch: enable NSH support
Date: Wed, 27 Sep 2017 09:39:09 +0800 [thread overview]
Message-ID: <20170927013908.GA33716@localhost.localdomain> (raw)
In-Reply-To: <20170926124914.60101ca1@griffin>
On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
> > After push_nsh, the packet won't be recirculated to flow pipeline, so
> > key->eth.type must be set explicitly here, but for pop_nsh, the packet
> > will be recirculated to flow pipeline, it will be reparsed, so
> > key->eth.type will be set in packet parse function, we needn't handle it
> > in pop_nsh.
>
> This seems to be a very different approach than what we currently have.
> Looking at the code, the requirement after "destructive" actions such
> as pushing or popping headers is to recirculate.
This is optimization proposed by Jan Scheurich, recurculating after push_nsh
will impact on performance, recurculating after pop_nsh is unavoidable, So
also cc jan.scheurich@ericsson.com.
Actucally all the keys before push_nsh are still there after push_nsh,
push_nsh has updated all the nsh keys, so recirculating remains avoidable.
>
> Setting key->eth.type to satisfy conditions in the output path without
> updating the rest of the key looks very hacky and fragile to me. There
> might be other conditions and dependencies that are not obvious.
> I don't think the code was written with such code path in mind.
>
> I'd like to hear what Pravin thinks about this.
>
> Jiri
next prev parent reply other threads:[~2017-09-27 1:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 14:16 [PATCH net-next v9] openvswitch: enable NSH support Yi Yang
2017-09-25 18:14 ` Jiri Benc
2017-09-26 4:55 ` Yang, Yi
2017-09-26 10:49 ` Jiri Benc
2017-09-27 1:39 ` Yang, Yi [this message]
2017-09-28 18:28 ` Pravin Shelar
2017-09-29 6:40 ` Yang, Yi
2017-09-29 7:10 ` Jan Scheurich
[not found] ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D7881A337-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-09-29 7:15 ` Yang, Yi
[not found] ` <20170929071553.GA19053-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2017-09-29 7:27 ` Jan Scheurich
2017-09-25 19:28 ` [ovs-dev] " Eric Garver
2017-09-26 5:02 ` Yang, Yi
2017-09-26 20:59 ` Eric Garver
2017-09-27 1:09 ` Yang, Yi
-- strict thread matches above, loose matches on Subject: below --
2017-09-14 8:37 Yi Yang
[not found] ` <1505378279-123916-1-git-send-email-yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-09-14 9:09 ` Jiri Benc
2017-09-18 7:14 ` Yang, Yi
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=20170927013908.GA33716@localhost.localdomain \
--to=yi.y.yang@intel.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=e@erig.me \
--cc=jan.scheurich@ericsson.com \
--cc=jbenc@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@ovn.org \
/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.