From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0064.outbound.protection.outlook.com [104.47.40.64]) by dpdk.org (Postfix) with ESMTP id 299032934 for ; Thu, 8 Dec 2016 23:07:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a0+kV8X2cxy/Av2ZzVL9nCuq+RnzVsbWyVA7yXQsaS4=; b=JcZ9cvAGN1R3jCMwXf9Db0RsX4z1jfRnyUoX3XoafeGN0ZKFwJkrjbS9qVXybNgecOepKfpLqGXf0T4T0d9+sCRB7O05k4/27pQ9ISAzAVEVGtz2FaiENjP069cjf2/gYR+dSwgFEjvjIEMzsJfHYpPfxeTEFxDMLJhP753zLu8= Received: from BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) by BN3PR03MB1496.namprd03.prod.outlook.com (10.163.35.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Thu, 8 Dec 2016 22:07:01 +0000 Received: from BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) by BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) with mapi id 15.01.0761.018; Thu, 8 Dec 2016 22:07:00 +0000 From: "Dey, Souvik" To: "Lu, Wenzhuo" , "dev@dpdk.org" CC: "Dai, Wei" Thread-Topic: ixgbevf: support multicast packets from PF to VF Thread-Index: AdJMwUeMIovxzxwPQU2ASbR+LZsrlAAABeeQAHZmrXAAI3HaEAAJYwuAAJQYfVA= Date: Thu, 8 Dec 2016 22:07:00 +0000 Message-ID: References: <6A0DE07E22DDAD4C9103DF62FEBC090939355C77@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC0909393561EC@shsmsx102.ccr.corp.intel.com> In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909393561EC@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sodey@sonusnet.com; x-originating-ip: [208.45.178.4] x-ms-office365-filtering-correlation-id: cd2f8ac0-8f29-46af-3571-08d41fb68901 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB1496; x-microsoft-exchange-diagnostics: 1; BN3PR03MB1496; 7:efLK5Idbaxsh5iJeIqDjw5lYKvzXc1IIbmudt0adfBPecSf4zksRGhbALPq1skhWjWmEFiIrX/zK+4mh0dyOXf4Pyia31lDDdEV5b5tMmODmK4nN8QUxSvK88MeGbPkvg/rqgtLpCGBL4O/MNZogHvhkauUDMwljM/ewuwFvhl7VVu9sxuy82tPsn2KIkZwAgm56PvxWwm1qFdQL27TBivtC31ryrVSUCZZRkwff+z22+jJzsCW53Ydbr+/DiJU0fBNUuhGUB42iEvvz4T++12diPLXQLWKR26ZktHodISxLPcuHfoUWceAA6i3Lvu7vPozcljMypNJ3Yk2Pl8+tGEXe5sXB2Uj7EaA/9vTsB5C/sBLA34DVpXU37IVf5C2KTlLcUGHPJCbqYG86LDzTSZC60tVvUA97IHEHB/IXZIDGMlDkVDQCrUi2+XbC3C2LisMGLp4fNnLova96K+9NFQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6047074)(6072148); SRVR:BN3PR03MB1496; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1496; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(199003)(377454003)(51874003)(53754006)(189002)(76576001)(68736007)(2950100002)(101416001)(9686002)(9326002)(229853002)(2906002)(4326007)(74316002)(189998001)(5001770100001)(76176999)(105586002)(606004)(99286002)(54356999)(97736004)(7736002)(7696004)(77096006)(8936002)(106356001)(50986999)(38730400001)(81166006)(66066001)(81156014)(5660300001)(86362001)(575784001)(8676002)(33656002)(2501003)(6116002)(790700001)(6506006)(102836003)(3660700001)(122556002)(3280700002)(3846002)(93886004)(3900700001)(92566002)(2900100001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR03MB1496; H:BN3PR03MB1494.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 22:07:00.7007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1496 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] ixgbevf: support multicast packets from PF to VF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:07:05 -0000 Hi Wenzhuo, Now I am using rte_eth_dev_set_mc_addr_list to configure th= e PF with the list of mc_addr supported by the VF, but interestingly only 1= of the mc_addr works and for other mc_addr packets does not even come up t= o the VF/DPDK PMD. PMD: ixgbe_update_mc_addr_list_vf(): ixgbe_update_mc_addr_list_vf PMD: ixgbe_update_mc_addr_list_vf(): MC Addr Count =3D 5 PMD: ixgbe_mta_vector(): MC Addr0 =3D 0,MC Addr1 =3D 1,mc_filter_type =3D= 0 PMD: ixgbe_update_mc_addr_list_vf(): Hash value =3D 0x010 PMD: ixgbe_mta_vector(): MC Addr0 =3D 0,MC Addr1 =3D 33,mc_filter_type = =3D0 PMD: ixgbe_update_mc_addr_list_vf(): Hash value =3D 0x210 PMD: ixgbe_mta_vector(): MC Addr0 =3D 0,MC Addr1 =3D 213,mc_filter_type = =3D0 PMD: ixgbe_update_mc_addr_list_vf(): Hash value =3D 0xD50 PMD: ixgbe_mta_vector(): MC Addr0 =3D 0,MC Addr1 =3D 14,mc_filter_type = =3D0 PMD: ixgbe_update_mc_addr_list_vf(): Hash value =3D 0x0E0 PMD: ixgbe_mta_vector(): MC Addr0 =3D 0,MC Addr1 =3D 78,mc_filter_type = =3D0 PMD: ixgbe_update_mc_addr_list_vf(): Hash value =3D 0x4E0 In the above list only the mc_aadr hash D50 works and the other 2 in RED f= ails to receive any multicast packets. Is there any other setting or reconf= iguration that is required to be done (both in DPDK or on PF) to get this w= orking all the configured MC_ADDRs ? I am using 2.1 DPDK on the guest and kernel 4.4 ixgbe PF drivers on the hos= t . -- Regards, Souvik From: Lu, Wenzhuo [mailto:wenzhuo.lu@intel.com] Sent: Monday, December 5, 2016 6:35 PM To: Dey, Souvik ; dev@dpdk.org Cc: Dai, Wei Subject: RE: ixgbevf: support multicast packets from PF to VF Hi Dey, I'm confused. rte_eth_allmulticast_enable means the port can receive all the multicast pa= ckets. In another word, it's multicast promiscuous mode. rte_eth_dev_set_mc_addr_list means adding a series of multicast addresses t= o the filter, so the port can receive these specific multicast packets. It'= s not promiscuous. During your test, I think only rte_eth_dev_set_mc_addr_list is working. rte= _eth_allmulticast_enable has no effect. As you mentioned the PF driver version, I'm afraid the problem is the PF. = When you call rte_eth_allmulticast_enable on VF, VF only sends a message to= PF. PF need to take action. So you must have a PF which can support this f= eature. From: Dey, Souvik [mailto:sodey@sonusnet.com] Sent: Tuesday, December 6, 2016 3:01 AM To: Lu, Wenzhuo >; dev@dp= dk.org Subject: RE: ixgbevf: support multicast packets from PF to VF Hi Wenzhuo, There is nothing set with the rte_eth_dev_set_mc_addr_list and we are tryin= g to receive the NS packet which has the destination MAC set as 33 33 ff 00= 00 14. Also what I saw is that the handling of allmulticast_enable message= in the kernel has happened after 4.0 version and the PF drivers which earl= ier kernel version will not support this. How should handle those scenarios= ? In my case too I tried 2 experiments : 1. Only set the rte_eth_allmulticast_enable from the DPDK app and I pa= tched the ixgbevf_pmd with our patch. The function was returning SUCCESS bu= t the NS packets were received in the application. 2. Then along with rte_eth_allmulticast_enable, I used the rte_eth_dev= _set_mc_addr_list to set the MAC 33 33 ff 00 00 14 from my app to the pmd. = After this I was successfully receiving the NS packets. But then the bigger= question is how to automate the addition of mc_addr in rte_eth_dev_set_mc_= addr_list as in the kni we are currently not using the kni_net_set_rx_mode(= ) function which is called by the net_device whenever the new mc_addr is as= signed to the net_device. -- Regards, Souvik From: Lu, Wenzhuo [mailto:wenzhuo.lu@intel.com] Sent: Sunday, December 4, 2016 9:02 PM To: Dey, Souvik >; dev@dpdk.o= rg Subject: RE: ixgbevf: support multicast packets from PF to VF Hi Souvik, To my opinion, rte_eth_dev_set_mc_addr_list has nothing to do with rte_eth_= allmulticast_enable. rte_eth_allmulticast_enable is enough for the multicas= t packets. I'm curious about the 1, what MAC addresses are set by rte_eth_dev_set_mc_a= ddr_list? 2, What multicast packets are sent? Thanks. Best regards Wenzhuo Lu From: Dey, Souvik [mailto:sodey@sonusnet.com] Sent: Saturday, December 3, 2016 1:28 AM To: dev@dpdk.org; Lu, Wenzhuo Subject: RE: ixgbevf: support multicast packets from PF to VF Adding wenzhuo.lu@intel.com From: Dey, Souvik Sent: Friday, December 2, 2016 12:27 PM To: 'dev@dpdk.org' > Subject: ixgbevf: support multicast packets from PF to VF Hi All, I am trying to support multicast packet over SRIOV using ke= rnel PF + DPDK VF(ixgbevf) drivers for ipv6. I am currently using 2.1 DPDK = and found that there was a patch in 16.04 for "ixgbe: support multicast pro= miscuous mode on VF". So I have backported the patch to the 2.1 DPDK but st= ill multicast packets were not coming up to the DPDK app. Then I tried to e= nable the rte_eth_dev_set_mc_addr_list and with the the packets were coming= up properly. Now I have some doubts : 1. Do we have to use both rte_eth_dev_set_mc_addr_list and rte_eth_all= multicast_enable to get the multicast packets. 2. How do we get the mc_addr_list dynamically as I don't see we are us= ing the kni_net_set_rx_mode in rte_kni. Without this the DPDK app will not = have any idea to update the mc_addr_list in the PF. 3. Is there any other patches which I should be using to get this func= tionality working. I am using : DPDK -2.1 Host kernel - 4.4 ( ubuntu) Guest kernel - 3.2 (Debian) Drivers - ixgbe ( for both pf and vf). Thanks in advance for the help and support. -- Regards, Souvik