On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote:
> > + nsh->md1.context[i] =
> > + OVS_MASKED(nsh->md1.context[i], key->context[i],
> > + mask->context[i]);
> > +
On Tue, Sep 05, 2017 at 11:46:45AM +0200, Jiri Benc wrote:
> On Tue, 5 Sep 2017 13:51:45 +0800, Yang, Yi wrote:
> > But if we follow your way, how does nla_for_each_nested handle such
> > pattern?
> >
> > attribute1
> > attribute1_mask
> > attribute2
> > attribute2_mask
> > attribute3
> > attribut
On Tue, Sep 05, 2017 at 11:47:41AM +0200, Jiri Benc wrote:
> On Tue, 5 Sep 2017 14:37:05 +0800, Yang, Yi wrote:
> > I checked source code but can't find where we can prepopulate it and how
> > we can deliver the prepopulated header to push_nsh, can you expand it in
> > order that I can know how to
> 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. A
On Mon, 4 Sep 2017 14:45:50 +, Jan Scheurich wrote:
> 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. Alt
On Tue, 5 Sep 2017 14:37:05 +0800, Yang, Yi wrote:
> I checked source code but can't find where we can prepopulate it and how
> we can deliver the prepopulated header to push_nsh, can you expand it in
> order that I can know how to do this in code level?
I already said that it's not implemented ye
On Tue, 5 Sep 2017 13:51:45 +0800, Yang, Yi wrote:
> But if we follow your way, how does nla_for_each_nested handle such
> pattern?
>
> attribute1
> attribute1_mask
> attribute2
> attribute2_mask
> attribute3
> attribute3_mask
Uh? That will just work. Note that nla len contains the size of the
wh
On Mon, Sep 04, 2017 at 06:42:16PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > how can we know next push_nsh uses the same nsh header as previous
> > one?
>
> We store the prepopulated header together with the action.
>
I checked source code but can't find whe
On Mon, Sep 04, 2017 at 08:57:44PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> > So we must do many changes if we want to break this assumption.
>
> We may do as many changes as we want to. This is uAPI we're talking
> about and we need to get it right since the
> On Mon, 4 Sep 2017 14:07:45 +, 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 components of the NSH header
On Mon, 4 Sep 2017 14:07:45 +, 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 components of the NSH header
> component
> > 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
>
On Mon, 4 Sep 2017 12:57:15 +, Jan Scheurich wrote:
> So is what you are suggesting the following?
>
> For matching:
> OVS_KEY_ATTR_NSH_BASE_HEADER mandatory
> OVS_KEY_ATTR_NSH_MD1_CONTEXT optional, in case MDTYPE == MD1
This needs to be:
OVS_KEY_ATTR_NSH
OVS_KEY_AT
On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote:
> +enum ovs_nsh_key_attr {
> + OVS_NSH_KEY_ATTR_BASE, /* struct ovs_nsh_key_base. */
> + OVS_NSH_KEY_ATTR_MD1, /* struct ovs_nsh_key_md1. */
> + OVS_NSH_KEY_ATTR_MD2, /* variable-length octets for MD type 2. */
> + __OVS_NSH_KE
> 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
> > user
On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> So we must do many changes if we want to break this assumption.
We may do as many changes as we want to. This is uAPI we're talking
about and we need to get it right since the beginning. Sure, it may
mean that some user space programs need some
On Mon, Sep 04, 2017 at 12:42:16PM +0200, Jiri Benc wrote:
> 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
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
> userspace, but ke
On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> > + mask->context[i]);
> > + }
> > + memcpy(flow_key->nsh.context, nsh->md1.context,
> > + sizeof(nsh->md1.context));
>
> Do you follow the discussion that Hannes Sowa
On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote:
> --- a/net/nsh/nsh.c
> +++ b/net/nsh/nsh.c
> @@ -14,6 +14,47 @@
> #include
> #include
>
> +int skb_push_nsh(struct sk_buff *skb, const struct nshhdr *nsh_src, bool
> is_eth)
> +{
> + struct nshhdr *nsh;
> + size_t length = nsh_hdr_l
v6->v7
- Remove NSH GSO patches in v6 because Jiri Benc
reworked it as another patch series and they have
been merged.
- Change it to adapt to nsh kernel module added by NSH
GSO patch series
v5->v6
- Fix the rest comments for v4.
- Add NSH GSO support for VxLAN-gpe + NSH and
Eth +
21 matches
Mail list logo
