> -Original Message-
> From: Jiri Benc [mailto:jb...@redhat.com]
> Sent: Friday, 11 August, 2017 11:45
>
> The context field does not apply to MD type 2. It looks wrong for the
> context field to be included in netlink attribute for anything other
> than MD type 1. Perhaps it needs to be
> From: Jiri Benc [mailto:jb...@redhat.com]
> Sent: Friday, 11 August, 2017 12:23
>
> On Fri, 11 Aug 2017 10:09:36 +, Jan Scheurich wrote:
> > Unless someone can explain to me why the datapath should understand the
> > internal structure/format of metadata in pu
> From: Jiri Benc [mailto:jb...@redhat.com]
> Sent: Monday, 14 August, 2017 09:51
>
> On Sun, 13 Aug 2017 21:13:57 +, Jan Scheurich wrote:
> > Jiri, I am not too familiar with conventions on the OVS netlink
> > interface regarding the handling of vari
> From: Jiri Benc [mailto:jb...@redhat.com]
> Sent: Monday, 14 August, 2017 12:48
>
> On Mon, 14 Aug 2017 10:35:42 +, Jan Scheurich wrote:
> > Is it worth to speculate on how a hypothetical future NSH version
> > (with a different Version value in the Base
Hi all,
In OVS 2.8 we support only fixed size NSH MD1 context data for matching and in
set/copy_field actions. OVS parses an MD2 NSH header but does not make any TLV
headers available to OF. The plan is to add support for matching/manipulating
NSH MD2 TLVs through a new infrastructure of
> > 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
> >> 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
> From: Yang, Yi [mailto:yi.y.y...@intel.com]
> Sent: Friday, 29 September, 2017 08:41
> To: Pravin Shelar <pshe...@ovn.org>
> Cc: Jiri Benc <jb...@redhat.com>; netdev@vger.kernel.org;
> d...@openvswitch.org; e...@erig.me; da...@davemloft.net; Jan Scheurich
&g
> > The optimization Yi refers to only affects the slow path translation.
> >
> > OVS 2.8 does not immediately trigger an immediate recirculation after
> > translating
> > encap(nsh,...). There is no need to do so as the flow key of the resulting
> > packet
> > can be determined from the encap()
> > If I understand correctly, this is a default definition that can be
> > overridden by drivers so that we still cannot rely on the Ethernet
> > payload always being 32-bit-aligned.
>
> Not by drivers, by architectures. Only architectures that can efficiently
> handle unaligned access (or on
> > struct nsh_hdr {
> > ovs_be16 ver_flags_ttl_len;
> > uint8_t mdtype;
> > uint8_t np;
> > ovs_16aligned_be32 path_hdr;
> > union {
> > struct nsh_md1_ctx md1;
> > struct nsh_md2_tlv md2[];
>
> I'm not that sure about this. With each member of md2 having a
> struct nsh_hdr {
> ovs_be16 ver_flags_ttl_len;
> uint8_t mdtype;
> uint8_t np;
> ovs_16aligned_be32 path_hdr;
> union {
> struct nsh_md1_ctx md1;
> struct nsh_md2_tlv md2;
> };
> };
>
The second member of the union should be a variable length array [] of
>
> The second member of the union should be a variable length array [] of
> struct nsh_md2_tlv
>
> struct nsh_hdr {
> ovs_be16 ver_flags_ttl_len;
> uint8_t mdtype;
> uint8_t np;
> ovs_16aligned_be32 path_hdr;
> union {
> struct nsh_md1_ctx md1;
> struct
> > NSH can be carried over Ethernet with a 14 byte header. In that case
> > the total NSH header would typically be 16-bit aligned, so that all
> > 32-bit members would be misaligned.
>
> See NET_IP_ALIGN in include/linux/skbuff.h.
If I understand correctly, this is a default definition that
> > [Mooney, Sean K]
> > Having the nsh context headers in the flow is quite useful It would
> > allow loadblancing on values stored in the context headers Or other
> > use. I belive odl previously used context header 4 to store a Flow id
> > so this could potentialy be used with the multipath
> >> >> 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]
> >> >
> >> 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
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > I think we have had similiar discussion about this, the issue is we have
> > no way to handle both MD type 1 and MD type 2 by using a common flow key
> > struct.
> >
> > So we have to do so, there is miniflow to handle such issue in
> >
> On Mon, 4 Sep 2017 14:07:45 +0000, Jan Scheurich wrote:
> > Then perhaps I misunderstood your comment. I thought you didn't like that
> > the
> > SET_MASKED action wrapped OVS_KEY_ATTR_NSH which in itself was nested.
> > I was aiming to avoid this by lifting the two c
> > So is what you are suggesting the following?
> >
> > For matching:
> > OVS_KEY_ATTR_NSH_BASE_HEADERmandatory
> > OVS_KEY_ATTR_NSH_MD1_CONTEXToptional, in case MDTYPE == MD1
>
> This needs to be:
>
> OVS_KEY_ATTR_NSH
> OVS_KEY_ATTR_NSH_BASE_HEADER
>
tch.org; jb...@redhat.com;
> e...@erig.me; b...@ovn.org; Jan Scheurich
> <jan.scheur...@ericsson.com>
> Subject: Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
>
> "Yang, Yi" <yi.y.y...@intel.com> writes:
>
> > I'm not sure what new actio
> From: Jiri Benc [mailto:jb...@redhat.com]
> > So what is the correct layout for MASKED_SET action with nested fields?
> > 1. All nested values, followed by all nested masks, or
> > 2. For each nested field value followed by mask?
> >
> > I guess alternative 1, but just to be sure.
>
> It's 2.
22 matches
Mail list logo
