On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote:
> "Yang, Yi" writes:
> >>
> >> > If you check GENEVE implementation, tun_metadata* can be set or matched
> >> > as any other match field.
> >>
> >> Yes, I wrote that in my previous mail. I wonder why NSH
Jan Scheurich 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
> > 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
Jan Scheurich writes:
>> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
>> >> is not in tun_metadata as well?
>> >
>> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
>> > not so, NSH can't directly use tun_metadata,
> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
> >> is not in tun_metadata as well?
> >
> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a
> > lot of rework on
"Yang, Yi" writes:
> On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote:
>> "Yang, Yi" writes:
>>
>> > We can change this later if we really find a better way to handle this
>> > because it isn't defined in
On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote:
> "Yang, Yi" writes:
>
> > We can change this later if we really find a better way to handle this
> > because it isn't defined in include/uapi/linux/openvswitch.h, so I still
> > have backdoor to do this
Hello Jan,
Jan Scheurich writes:
> Please have a look at the Google doc that sketches the overall
> solution to support NSH in OVS.
> https://drive.google.com/open?id=1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8
>
> In details it is slightly outdated but the NSH MD1
"Yang, Yi" writes:
> On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:
>> "Yang, Yi" writes:
>>
>> > I'm not sure what new action you expect to bring here, I think group
>> > action is just for this, as you said it isn't only bound
Hi Hannes,
Please have a look at the Google doc that sketches the overall solution to
support NSH in OVS.
https://drive.google.com/open?id=1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8
In details it is slightly outdated but the NSH MD1 support (and all
prerequisites like PTAP and Generic
On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:
> "Yang, Yi" writes:
>
> > I'm not sure what new action you expect to bring here, I think group
> > action is just for this, as you said it isn't only bound to NSH, you can
> > start a new thread to
On Mon, Sep 04, 2017 at 07:22:26PM +0800, Hannes Frederic Sowa wrote:
> Hello,
>
> "Yang, Yi" writes:
>
> > On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> >> Hello,
> >>
> >> Yi Yang writes:
> >>
> >> [...]
> >>
> >> >
> >> Does it makes sense to keep the context headers as part of the flow?
> >> What is the reasoning behind it? With mdtype 2 headers this might either
> >> not work very well or will increase sw_flow_key size causing slowdowns
> >> for all protocols.
> >
> > For userspace, miniflow can handle
Hello,
Jan Scheurich writes:
>> >> >> Does it makes sense to keep the context headers as part of the flow?
>> >> >> What is the reasoning behind it? With mdtype 2 headers this might
>> >> >> either not work very well or will increase sw_flow_key size causing
>> >> >>
Hello,
"Yang, Yi" writes:
> On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
>> Hello,
>>
>> Yi Yang writes:
>>
>> [...]
>>
>> > +struct ovs_key_nsh {
>> > + u8 flags;
>> > + u8 ttl;
>> > + u8 mdtype;
>> > + u8 np;
>> > +
> >> >> Does it makes sense to keep the context headers as part of the flow?
> >> >> What is the reasoning behind it? With mdtype 2 headers this might
> >> >> either not work very well or will increase sw_flow_key size causing
> >> >> slowdowns for all protocols.
> >> > [Mooney, Sean K]
> >> >
On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> Hello,
>
> Yi Yang writes:
>
> [...]
>
> > +struct ovs_key_nsh {
> > + u8 flags;
> > + u8 ttl;
> > + u8 mdtype;
> > + u8 np;
> > + __be32 path_hdr;
> > + __be32
Hello,
"Mooney, Sean K" writes:
[...]
>> >> > +struct ovs_key_nsh {
>> >> > + u8 flags;
>> >> > + u8 ttl;
>> >> > + u8 mdtype;
>> >> > + u8 np;
>> >> > + __be32 path_hdr;
>> >> > + __be32 context[NSH_MD1_CONTEXT_SIZE]; };
>> >> > +
ernel.org; jb...@redhat.com; e...@erig.me
> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH
> support
>
> "Mooney, Sean K" <sean.k.moo...@intel.com> writes:
>
> >> -Original Message-
> >> From: ovs-dev-boun...@openvswitch.
t...@vger.kernel.org; jb...@redhat.com;
> e...@erig.me
> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH
> support
>
> Hello,
>
> Yi Yang <yi.y.y...@intel.com> writes:
>
> [...]
>
> > +struct ovs_key_nsh {
> > + u8 flags;
&
Hello,
Yi Yang writes:
[...]
> +struct ovs_key_nsh {
> + u8 flags;
> + u8 ttl;
> + u8 mdtype;
> + u8 np;
> + __be32 path_hdr;
> + __be32 context[NSH_MD1_CONTEXT_SIZE];
> +};
> +
> struct sw_flow_key {
> u8 tun_opts[IP_TUNNEL_OPTS_MAX];
>
OVS master and 2.8 branch has merged NSH userspace
patch series, this patch is to enable NSH support
in kernel data path in order that OVS can support
NSH in compat mode by porting this.
Signed-off-by: Yi Yang
---
drivers/net/vxlan.c | 7 +
22 matches
Mail list logo