public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion•org>
To: Jan Scheurich <jan.scheurich@ericsson•com>
Cc: "Yang\, Yi" <yi.y.yang@intel•com>,
	"netdev\@vger.kernel.org" <netdev@vger•kernel.org>,
	"dev\@openvswitch.org" <dev@openvswitch•org>,
	"jbenc\@redhat.com" <jbenc@redhat•com>, "e\@erig.me" <e@erig•me>,
	"blp\@ovn.org" <blp@ovn•org>
Subject: Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
Date: Wed, 06 Sep 2017 12:02:42 +0200	[thread overview]
Message-ID: <8760cwuou5.fsf@stressinduktion.org> (raw)
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5ECB@ESESSMB107.ericsson.se> (Jan Scheurich's message of "Wed, 6 Sep 2017 09:54:08 +0000")

Jan Scheurich <jan.scheurich@ericsson•com> writes:

>> > There is no way we can re-use the existing TLV tunnel metadata
>> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We
>> > will need to introduce a new (perhaps similar) scheme for modelling
>> > generic TLV match registers in OVS that are assigned to protocol TLVs
>> > by the controller. This is FFS.
>> 
>> This is what I don't understand.
>> 
>> Why can't you just reuse the space in the struct sw_flow_key where
>> geneve would put in their metadata. There are 255 empty bytes at the
>> beginning if you don't have other tunnel metadata anyway.
>> 
>> If you receive packets over vxlan(gpe), tun_opts gets populated with an
>> ip_tunnel_key. Couldn't you use the options space in there after the
>> ip_tunnel_key to store the NSH context just for the sake of storing them
>> somewhere instead of adding 16 bytes to sw_flow_key?
>
> There is a significant conceptual difference between tunnel metadata
> (copied from a popped tunnel header) and packed match fields extracted
> during parsing of the packets. If we'd store them in the same space in
> the sw_flow_key struct, we are calling for trouble.
>
> NSH is transport agnostic, it should work over Ethernet, VXLAN(GPE)
> and other transport tunnels. Think about an NSH packet arriving on an
> Geneve tunnel port. Any Geneve tunnel options have already been stored
> in the tun_opts metadata bytes. Now the datapath parses the NSH header
> and overwrites the tun_opts metadata with the NSH metadata. This would
> break the OVS semantics.

Obviously you would use key->tun_opts_len and start appending there and
not simply overwrite. Otherwise that would be rather silly.

> I absolutely understand your concern about efficient space utilization
> in the flow struct for TLV match fields and it will be part of the
> design challenge for MD2 TLV support to find a good balance between
> memory and run-time efficiency. But that is FFS. For the four fixed
> size MD1 headers the decision has been to include them as additional
> attributes in the flow key.

Okay, then.

Bye,
Hannes

  reply	other threads:[~2017-09-06 10:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 14:20 [PATCH net-next v6 0/3] openvswitch: add NSH support Yi Yang
2017-08-25 14:20 ` [PATCH net-next v6 1/3] net: add NSH header structures and helpers Yi Yang
2017-08-25 15:07   ` Jiri Benc
2017-08-25 14:20 ` [PATCH net-next v6 2/3] net: gso: Add GSO support for NSH Yi Yang
2017-08-25 16:25   ` Jiri Benc
2017-08-25 23:22     ` Jiri Benc
2017-08-25 14:20 ` [PATCH net-next v6 3/3] openvswitch: enable NSH support Yi Yang
2017-08-30  9:53   ` Hannes Frederic Sowa
     [not found]     ` <87wp5l7560.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-08-30 11:36       ` Mooney, Sean K
2017-08-30 15:15         ` [ovs-dev] " Hannes Frederic Sowa
     [not found]           ` <87inh56q8u.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-08-30 19:00             ` Mooney, Sean K
2017-08-31 12:49               ` [ovs-dev] " Hannes Frederic Sowa
2017-09-04  9:38                 ` Jan Scheurich
2017-09-04 11:45                   ` Hannes Frederic Sowa
2017-09-01 12:11             ` Jan Scheurich
2017-09-04  2:38       ` Yang, Yi
2017-09-04 11:22         ` Hannes Frederic Sowa
2017-09-04 11:57           ` Jan Scheurich
     [not found]           ` <87mv6abte5.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-09-05  2:11             ` Yang, Yi
     [not found]               ` <20170905021112.GA86057-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
2017-09-05 10:30                 ` Hannes Frederic Sowa
     [not found]                   ` <87vakxsaj2.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-09-05 11:38                     ` Yang, Yi
     [not found]                       ` <20170905113848.GC92895-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
2017-09-05 13:12                         ` Hannes Frederic Sowa
     [not found]                           ` <878thtmgra.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-09-06  0:53                             ` Yang, Yi
     [not found]                               ` <20170906005359.GA103260-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
2017-09-06  8:03                                 ` Hannes Frederic Sowa
     [not found]                                   ` <87o9qo9ru6.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-09-06  8:27                                     ` Jan Scheurich
     [not found]                                       ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5D2E-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-09-06  9:37                                         ` Hannes Frederic Sowa
     [not found]                                           ` <87bmmo9ngt.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2017-09-06  9:54                                             ` Jan Scheurich
2017-09-06 10:02                                               ` Hannes Frederic Sowa [this message]
2017-09-06 11:03                                     ` Yang, Yi
2017-09-05 12:19                   ` Jan Scheurich
     [not found]                     ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5650-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-09-05 13:34                       ` Hannes Frederic Sowa

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=8760cwuou5.fsf@stressinduktion.org \
    --to=hannes@stressinduktion$(echo .)org \
    --cc=blp@ovn$(echo .)org \
    --cc=dev@openvswitch$(echo .)org \
    --cc=e@erig$(echo .)me \
    --cc=jan.scheurich@ericsson$(echo .)com \
    --cc=jbenc@redhat$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=yi.y.yang@intel$(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