netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH net-next v2] openvswitch: enable NSH support
Date: Fri, 11 Aug 2017 16:47:23 +0800	[thread overview]
Message-ID: <20170811084722.GA19968@cran64.bj.intel.com> (raw)
In-Reply-To: <20170811102418.6b1be4f7@griffin>

On Fri, Aug 11, 2017 at 10:24:18AM +0200, Jiri Benc wrote:
> On Thu, 10 Aug 2017 21:21:15 +0800, Yi Yang wrote:
> > 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 2.8 release in compat mode by porting this.
> 
> Please include changelog when posting a new version of a patch.
> 
> > +static inline u16
> > +nsh_hdr_len(const struct nsh_hdr *nsh)
> 
> Single line, please. And all other instances of this in nsh.h, too.

Thanks Jiri, I'll change these in next version.

> 
> > --- a/include/uapi/linux/openvswitch.h
> > +++ b/include/uapi/linux/openvswitch.h
> > @@ -333,6 +333,7 @@ enum ovs_key_attr {
> >  	OVS_KEY_ATTR_CT_LABELS,	/* 16-octet connection tracking label */
> >  	OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4,   /* struct ovs_key_ct_tuple_ipv4 */
> >  	OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6,   /* struct ovs_key_ct_tuple_ipv6 */
> > +	OVS_KEY_ATTR_NSH,                  /* struct ovs_key_nsh */
> >  
> >  #ifdef __KERNEL__
> >  	OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ip_tunnel_info */
> > @@ -491,6 +492,15 @@ struct ovs_key_ct_tuple_ipv6 {
> >  	__u8   ipv6_proto;
> >  };
> >  
> > +struct ovs_key_nsh {
> > +	__u8 flags;
> > +	__u8 mdtype;
> > +	__u8 np;
> > +	__u8 pad;
> > +	__be32 path_hdr;
> > +	__be32 c[4];
> 
> I still don't like the "c" name. Please change it to something
> descriptive. This is uAPI and can't be changed later.

is "__be32 context[4]" ok?

> 
> And I still don't see my comment about this not being extensible for
> MD type 2 addressed. Please understand this is uAPI and it is set in
> stone once it is merged into the kernel. It's very important we get
> this right since the beginning.

I understood it, but I don't know how I can do this per your comments,

Per Ben's comments,

PUSH_NSH message looks like

PUSH_NSH begin
    nsh base header
    MD type 1
PUSH_NSH end

or 

PUSH_NSH begin
    nsh base header
    MD type 2
PUSH_NSH end

If so, I think we don't need struct ovs_action_push_nsh at all, just as
_CT action did, treat it as a variable data buffer.

So define three new netlink attributes

OVS_ACTION_ATTR_NSH_BASE_HEADER
OVS_ACTION_ATTR_NSH_MD1_DATA
OVS_ACTION_ATTR_NSH_MD2_DATA

OVS_ACTION_ATTR_PUSH_NSH is nested netlink attribute, it will nest
OVS_ACTION_ATTR_NSH_BASE_HEADER and OVS_ACTION_ATTR_NSH_MD1_DATA for MD
type 1, it will nest OVS_ACTION_ATTR_NSH_BASE_HEADER and
OVS_ACTION_ATTR_NSH_MD2_DATA for MD type 2. I'll compeletely remove struct
ovs_action_push_nsh, is it ok?

> 
> > +struct ovs_action_push_nsh {
> > +	__u8 flags;
> > +	__u8 mdtype;
> > +	__u8 mdlen;
> > +	__u8 np;
> > +	__be32 path_hdr;
> > +	__u8 metadata[];
> > +};
> 
> This is not how netlink attributes work. Please reread Ben Pfaff's
> explanation on how this needs to be structured (Message-ID:
> <20170809180912.GU6175-LZ6Gd1LRuIk@public.gmane.org>) and rework the patch. I 100% agree
> with what he wrote, his proposal is very clean and matches how netlink
> is designed.
> 
> > @@ -835,6 +866,8 @@ enum ovs_action_attr {
> >  	OVS_ACTION_ATTR_TRUNC,        /* u32 struct ovs_action_trunc. */
> >  	OVS_ACTION_ATTR_PUSH_ETH,     /* struct ovs_action_push_eth. */
> >  	OVS_ACTION_ATTR_POP_ETH,      /* No argument. */
> > +	OVS_ACTION_ATTR_PUSH_NSH,     /* struct ovs_action_push_nsh. */
> > +	OVS_ACTION_ATTR_POP_NSH,      /* No argument. */
> 
> Thank you for changing this to push/pop, it looks much cleaner now.
> 
> > +static int parse_nsh(struct sk_buff *skb, struct sw_flow_key *key)
> > +{
> > +	struct nsh_hdr *nsh = (struct nsh_hdr *)skb_network_header(skb);
> > +	u16 ver_flags_len;
> > +	u8 version, length;
> > +	u32 path_hdr;
> > +	int i;
> > +
> > +	memset(&key->nsh, 0, sizeof(struct ovs_key_nsh));
> > +	ver_flags_len = ntohs(nsh->ver_flags_len);
> > +	version = (ver_flags_len & NSH_VER_MASK) >> NSH_VER_SHIFT;
> > +	length = (ver_flags_len & NSH_LEN_MASK) >> NSH_LEN_SHIFT;
> 
> A nit: the operation to get/set version, length and flags from the NSH
> header seems to be repeated enough to warrant helper functions in
> include/net/nsh.h. Something like:
> 
> static inline u8 nsh_get_version(const struct nsh_hdr *nsh)
> {
> 	return (ntohs(nsh->ver_flags_len) & NSH_VER_MASK) >> NSH_VER_SHIFT;
> }
> 
> etc.
> 
> Not a blocker, though, it may be done later if needed.

Ok, will change it.

> 
> > @@ -76,9 +77,11 @@ static bool actions_may_change_flow(const struct nlattr *actions)
> >  
> >  		case OVS_ACTION_ATTR_CT:
> >  		case OVS_ACTION_ATTR_HASH:
> > +		case OVS_ACTION_ATTR_POP_NSH:
> >  		case OVS_ACTION_ATTR_POP_ETH:
> >  		case OVS_ACTION_ATTR_POP_MPLS:
> >  		case OVS_ACTION_ATTR_POP_VLAN:
> > +		case OVS_ACTION_ATTR_PUSH_NSH:
> >  		case OVS_ACTION_ATTR_PUSH_ETH:
> >  		case OVS_ACTION_ATTR_PUSH_MPLS:
> >  		case OVS_ACTION_ATTR_PUSH_VLAN:
> 
> Alphabetical order, please.

Ok, will change.
> 
> Thanks,
> 
>  Jiri

  reply	other threads:[~2017-08-11  8:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10 13:21 [PATCH net-next v2] openvswitch: enable NSH support Yi Yang
     [not found] ` <1502371275-52446-1-git-send-email-yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-08-11  8:24   ` Jiri Benc
2017-08-11  8:47     ` Yang, Yi [this message]
2017-08-11  9:10       ` Jiri Benc
2017-08-11  9:24         ` Yang, Yi Y
2017-08-11  9:44           ` Jiri Benc
2017-08-11  9:54             ` Yang, Yi
2017-08-11 10:09             ` Jan Scheurich
     [not found]               ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D7273679A-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-08-11 10:22                 ` Jiri Benc
2017-08-13 21:13                   ` Jan Scheurich
     [not found]                     ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D72736EAE-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-08-14  7:51                       ` Jiri Benc
2017-08-14 10:35                         ` Jan Scheurich
     [not found]                           ` <CFF8EF42F1132E4CBE2BF0AB6C21C58D727373EA-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
2017-08-14 10:47                             ` Jiri Benc
2017-08-14 11:08                               ` Jan Scheurich
2017-08-11 10:35               ` Jiri Pirko
2017-08-14 16:09   ` Eric Garver
2017-08-15  0:39     ` 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=20170811084722.GA19968@cran64.bj.intel.com \
    --to=yi.y.yang-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
    --cc=jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).