On Wed, Jul 13, 2016 at 01:36:14AM +0800, Johnson Li wrote:
> Openvswitch could use the fields of Network Serivce Header(NSH)
> as key to steer traffic to the Virtual Network Functions(VNF).
> The key will contain fields for NSH base header, service path
> header and context header for MD type 1. For MD type 2, will
> reuse the field definition tun_opts.
>
> Signed-off-by: Johnson Li <johnson...@intel.com>
>
> diff --git a/datapath/flow.c b/datapath/flow.c
> index c97c9c9..fd09cec 100644
> --- a/datapath/flow.c
> +++ b/datapath/flow.c
> @@ -489,6 +489,9 @@ static int key_extract(struct sk_buff *skb, struct
> sw_flow_key *key)
> skb_reset_mac_len(skb);
> __skb_push(skb, skb->data - skb_mac_header(skb));
>
> + /* Network Service Header */
> + memset(&key->nsh, 0, sizeof(key->nsh));
This seems to be an expensive per-packet cost.
I wonder if clearing the nsh key could be avoided in the general case.
Or if an abbreviated mechanism could be used - e.g. setting the nsp field
to 0.
> +
> /* Network layer. */
> if (key->eth.type == htons(ETH_P_IP)) {
> struct iphdr *nh;
> diff --git a/datapath/flow.h b/datapath/flow.h
> index c0b628a..6ac96c3 100644
> --- a/datapath/flow.h
> +++ b/datapath/flow.h
> @@ -54,10 +54,25 @@ struct ovs_tunnel_info {
> (offsetof(struct sw_flow_key, recirc_id) + \
> FIELD_SIZEOF(struct sw_flow_key, recirc_id))
>
> +/* Network Service Header.
> + */
> +struct ovs_nsh_key {
> + u8 flags;
> + u8 md_type; /* NSH metadata type */
> + u8 next_proto; /* NSH next protocol */
> + u8 nsi; /* NSH index */
> + u32 nsp; /* NSH path id */
My understanding is that the nsp is only 24-bits wide.
Would it make sense for the nsp and nsi to share a single u32?
[...]
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
