From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <andrey.chilikin@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id A956A7E99
 for <dev@dpdk.org>; Thu, 23 Oct 2014 10:59:30 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga101.fm.intel.com with ESMTP; 23 Oct 2014 02:07:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="404706864"
Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153])
 by FMSMGA003.fm.intel.com with ESMTP; 23 Oct 2014 02:00:11 -0700
Received: from irsmsx106.ger.corp.intel.com ([169.254.8.179]) by
 IRSMSX101.ger.corp.intel.com ([169.254.1.144]) with mapi id 14.03.0195.001;
 Thu, 23 Oct 2014 10:06:31 +0100
From: "Chilikin, Andrey" <andrey.chilikin@intel.com>
To: "Liu, Jijiang" <jijiang.liu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH v6 5/9] librte_ether:add data structures of
 VxLAN filter
Thread-Index: AQHP7QuJFKbMRL7JK0C/1AlzdyzoJ5w6ItQAgAE5OcD///mOAIAAnkYggAFw8MA=
Date: Thu, 23 Oct 2014 09:06:30 +0000
Message-ID: <AAC06825A3B29643AF5372F5E0DDF0533500D140@IRSMSX106.ger.corp.intel.com>
References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com>
 <1893361.J7EnPDFulE@xps13>
 <1ED644BD7E0A5F4091CF203DAFB8E4CC01D827DB@SHSMSX101.ccr.corp.intel.com>
 <1475006.YvKxECmGku@xps13>
 <1ED644BD7E0A5F4091CF203DAFB8E4CC01D829F1@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D829F1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v6 5/9] librte_ether:add data structures of
 VxLAN filter
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Oct 2014 08:59:34 -0000

For me these defines make perfect sense - tunnelling filters require combin=
ations of different tunnel components, but not all combinations are valid. =
So defining valid combinations separately helps.=20

Regards,
Andrey

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 22, 2014 5:31 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 5/9] librte_ether:add data=20
> structures of VxLAN filter
>=20
> 2014-10-22 02:25, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2014-10-21 16:46, Jijiang Liu:
> > > > +#define RTE_TUNNEL_FILTER_IMAC_IVLAN (ETH_TUNNEL_FILTER_IMAC
> | \
> > > > +					ETH_TUNNEL_FILTER_IVLAN)
> > > > +#define RTE_TUNNEL_FILTER_IMAC_IVLAN_TENID
> (ETH_TUNNEL_FILTER_IMAC | \
> > > > +					ETH_TUNNEL_FILTER_IVLAN | \
> > > > +					ETH_TUNNEL_FILTER_TENID)
> > > > +#define RTE_TUNNEL_FILTER_IMAC_TENID (ETH_TUNNEL_FILTER_IMAC
> | \
> > > > +					ETH_TUNNEL_FILTER_TENID)
> > > > +#define RTE_TUNNEL_FILTER_OMAC_TENID_IMAC
> (ETH_TUNNEL_FILTER_OMAC | \
> > > > +					ETH_TUNNEL_FILTER_TENID | \
> > > > +					ETH_TUNNEL_FILTER_IMAC)
> > >
> > > I thought you agree that these definitions are useless?
> >
> > Sorry, this MAY be  some misunderstanding, I don't think these=20
> > definition are useless. I just thought change "uint16_t filter_type"
> > is better than define "enum filter_type".
> >
> > Let me explain here again.
> > The filter condition are:
> > 1.  inner MAC + inner VLAN
> > 2. inner MAC + IVLAN + tenant ID
> > ..
> > 5. outer MAC + tenant ID + inner MAC
> >
> > For each filter condition, we need to check if the mandatory=20
> > parameters are valid by checking corresponding bit MASK.
>=20
> Checking bit mask doesn't imply to define all combinations of bit masks.
> There's probably something obvious that one of us is missing.

Anybody else have comments on this?=20

> > An pseudo code example:
> >
> >        Switch (filter_type)
> >        Case 1:  //inner MAC + inner VLAN
> > 	If (filter_type & ETH_TUNNEL_FILTER_IMAC )
> >                             if   (IMAC=3D=3DNULL)
> >                                       return -1;
> >
> >        case 5: // outer MAC + tenant ID + inner MAC
> >             If (filter_type & ETH_TUNNEL_FILTER_IMAC )
> >                             if   (IMAC=3D=3DNULL)
> >                                       return -1;
> >
> >              If (filter_type & ETH_TUNNEL_FILTER_OMAC )
> >                             if   (IMAC=3D=3DNULL)
> >                                       return -1;
> >    ......