From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0085.outbound.protection.outlook.com [104.47.34.85]) by dpdk.org (Postfix) with ESMTP id 0FD558DA1 for ; Wed, 14 Sep 2016 13:28:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0oTBn7d+5Zf1mnGhdI/sXiSDxe9ZSoJMiBY1EKstWGE=; b=nlL6TwY+eQz8LPfuf/ZD2rvEY1peg9RguAhhf5uTIRL5qwWG6Ltgsfx0y1WHbXk9ezTT383azFSSe2VSYu92C7BLonqW3vL4AJsRQ/DsfCmcxD+IhPrehDNi8rWcxC2sAMNAJm3Oqw8X1QQG4GXt+5fozd65WSD3RE4lCMTblN4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.171.57.109) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 14 Sep 2016 11:28:35 +0000 Date: Wed, 14 Sep 2016 16:58:13 +0530 From: Jerin Jacob To: "ZELEZNIAK, ALEX" CC: Bernard Iremonger , "rahul.r.shah@intel.com" , "wenzhuo.lu@intel.com" , "dev@dpdk.org" Message-ID: <20160914112811.GA8364@localhost.localdomain> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1472202620-20487-1-git-send-email-bernard.iremonger@intel.com> <1472202620-20487-2-git-send-email-bernard.iremonger@intel.com> <20160909141031.GA4100@localhost.localdomain> <3C0218D8B3DD114D8DBFE6B68141FBE3185F9FE7@MISOUT7MSGUSRDI.ITServices.sbc.com> <20160913084535.GA6750@localhost.localdomain> <3C0218D8B3DD114D8DBFE6B68141FBE3185FDCDC@MISOUT7MSGUSRDI.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3C0218D8B3DD114D8DBFE6B68141FBE3185FDCDC@MISOUT7MSGUSRDI.ITServices.sbc.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-Originating-IP: [122.171.57.109] X-ClientProxiedBy: PN1PR01CA0067.INDPRD01.PROD.OUTLOOK.COM (10.164.136.167) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: c8a8c0cf-58c2-4c7d-9b97-08d3dc9245a0 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:r3Bw01BXvic4jXlNk6HhcJSjTXIrkEeerRe1P51f7T3DIDv2MGXQYBWTMUpPtmQylqbaINZuVWkdVj3C/qkWs3J4Z0SbRrcSA9UpqAx/9yF+lQjMpuC8iU4YCJ9jUNd+dMI1ICFRq6/mYIH0K4WpPMecLgEo/aNgFsXwu+V+Tz3yThKYThQNtfmsz2ghTxNN; 3:kGM4rdoqk8EUrzgtFljji7j+Iq+p8g6NGq0F2Fc8rF0VdnM2aw1dgQb8+IClnCMFi5LmzX9MiYrtRP+yPaAxg0Cmsm9RWTBZW9SHZtATUHHqAKOJy9V+Rik6SpXjvOhB X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 25:m/ysgciIq62ZZzWkAMb/uWXyWtendWacQeqkUZwCXaor38IdtdZWHO+iOaYfYafyvsEQoLGFEuwetO27TuyGm4c+oQ7OVnslbbD982bJuWl+Lc1/ldEKZG9Wbuv23df9kAUnoRLPfd6GNnS38UCpvQrg0p4fZMvhcVqKYttDklZfyOJjLNRek+6x6bHzw9wvIHuQhqLrh83jEUM+hjlrwmVa308emfmJnaGg0XU61TGACiXLWo99Ac330mpbL5C/72/m4aEHsw8Y0f1tD8BAgAhzK+qNQRpZ3ujx1dI22XuOIfMTn3h981apEoRdgx7n3skgNzq/lJx9elTfnfF7D/m9T0uKdI2mxazOCRE/UDDZkBPEQyewm9ZH83wRUcxmP0caHTjylLFcYN9Kv7BMH8/UT71NEqSoZtTkVCcBXCps7UV0IkyGBlJ7NEvTH+/ZCfbF6xTg9S54X8xTPekcyXfx4jNfhAIRMs6IEgDMFYIPpr/xhOfLNhUnFbRHRQgw0QeMT7S36tegtepguwDtArXUwNC4hGF3AIvjRVt786MceG6N964tVCHOqUX9gleLsFoGw+P7W32/tbSr8sNbU/EqGhGmbMauadWHk8qF+SSQ+vyIk2qJ55jXE8TxhWGnR0Dxs1WczfRiUxllz1M+1QpTLOk5UrMxlueg7iFouh2Sto9Kc+KjDAktOSIdicdqq+Rp74+gaV+2aV5zQuhKD0I/kUgYXKeiQXvqmYL7JADjy72+Y7oWZoEB2KSCF2/w6lVWCIIxOjj6fwrbKNhSldzqs4tBxhfT+7ulNlxVZNE= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 31:0MQEDPgpG7tFxNLtSB+lDnfGItdXuAYuOhfFcRPCNyNJEfnb9vled6v1q+SHNgcR+h5lqdKdyF4q+gKwi/cWr1LVoKsNtNDPWgtgxWEFj5JO46qjloW2L9Dqo9ca0P8cY95h9PbLmCZ76xvu2VA8GK8hwxCaacyLIgRDEktx15MfLGHtWOHc8pYufYEDZi9DY0sNmn5z0eTb7vciDjHav6O8/221dz4cqha4LyDrjUk=; 20:alWie7oQnoll++Ybhipi1F3htH//BejCj1VyYTBBi3a20CKC4lXldZLJcwOeEyzWbrE4XcR4/o3hrwaAxkGsapL4swQG9xjmNtkCPGjvnciwEYsVDYNERj3iHsbIOB7UGhfgtts8UDsffC5kUd9Rubuvr5q0u4gpkmxtg3NqZ5nbv4vJG9dfIMRo08wzaliPSlQ7jKPKM8IlykUbuE2NF5j+IMQMnRUbfZGnhuMPibcOzzs4z61RvhOia6A5DdERoK3iLiejxspV8YYBgPwPPEFKDJZ2DxrQvVbWDFSTdKvR+OLUHvKka2a8RG/3BolNRll56XAt+aIEluaaYoPaAdrf1PWbrhovnxVpUw0LwluiAnFdcX2ISMVUAjndjvV6dyWuvq9gxtEVE8Qf+cDiSPEYsT2qyufxCiIa+dm9qSNw92oJAd+hPXWuDW9UT4xCHPfOh82xfl3Ad7ae0T1wIKtp1ZzwlF+u9o+KpW6AHovJCdcYbnJqnJcGtylXirs00iHAX+/xJZ7ZOJxwcFv68djVe7ixuHu7eYK9llqsYhyhNmZq3Ji4kR8QNDRja43/kQK13qgq13GTJZtxaxTpynFG8idSd4zxEP18DJ7kKoA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(97927398514766)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:YGilfZkHU5mBMR0sxdxxGyikpr7JqnChOxU/I0fwYQn79F9JZiMQEq0xHy9mz8jksTOjxDHwO5uxWEJtBOTheklD5okyGc3Lc7K6+9/XPXhrYDlaJ1ESRguizcDJY6wWCsHndqMxvIlfjLpxK1EICRJs5WWRD+kFLcwR0oEbGIa8uICyZGLiiyZgNcfZpcS/yFoUOO3HJeLX3roTQqH2d0EI/xTRPMMPrtDDjP5Z6QdGZSRQmFtjQW/yQ8Lnd783jRScpjzfllhuAm+C4pYmvlOCulJTdiWkjENk98tDEWaR7UCFyK+sMx2pCLKPJE/7vBwRYA31LR++TuWHhqBS3aBYG8g1j+Zj+H6qcFgvXxhoImKV+8thIHiLqEUlUYakN2De163B0us6o6lztOImE/K3hrZBiKYlIEuz9SyB0dQ2ggGT/U0RtfarzIAhwbW8qHNG3/QTNPvLgsw5eIgxD7S6TtAnu91mBaWHuxA//kvG1FqKT4krvfKIRmuYZXng X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(189002)(199003)(24454002)(13464003)(76094002)(377454003)(4001350100001)(97736004)(76176999)(54356999)(93886004)(47776003)(97756001)(33656002)(83506001)(50986999)(81166006)(66066001)(77096005)(92566002)(4326007)(81156014)(101416001)(8676002)(5660300001)(2950100001)(50466002)(586003)(2906002)(46406003)(106356001)(7846002)(105586002)(61506002)(189998001)(7736002)(305945005)(42186005)(19580405001)(9686002)(575784001)(1076002)(3846002)(68736007)(23726003)(6116002)(19580395003)(110136003)(18370500001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:MfBMtzBRzaRe7F0+38fJokegsSYxBoHdJHArBIz?= =?us-ascii?Q?Q+7KNpVx5JsG+vQyK8dW3+TpsQB/atEw8rnrqQsQXUPYIC9isW360uS/KPUk?= =?us-ascii?Q?a39yVvuL/U41QPjSjGG+xcrgMYFRvzZC270rXbl9UeRrvku5sHTdtFKpAb9r?= =?us-ascii?Q?qRiAX9WkYqr9zgy5tFceAQ4BMCzxmzs53gbQhMvUhU6OT3VvWMck3E05vAl4?= =?us-ascii?Q?EcSnYzjMNJqGDMB6HlyView/or1GAjEF4DefAH/T9mG1PvbsgA28V9jRFs7E?= =?us-ascii?Q?9BhXBLAbC9exHy6136lrhLhLCJ82GwJBIntKMLq2SHaNkjfWz/wVp5hyW15P?= =?us-ascii?Q?fJkDC4thxjqWU/IVD16PTxL9GngnDjdXjdB0RE8e/R4Vvq5pwnQxBliMcG14?= =?us-ascii?Q?wq8uM+fOSItIJiWc0DPmT5u1E8GCDrJbShhs+nMUvky8Ve7/hzFM2AWpOjBk?= =?us-ascii?Q?rlns1cPbZuBqBUXRHxZ8X33h9UAd4qpYHduD4uB2PPPEclHSwp06YF1ognmi?= =?us-ascii?Q?cEUhHFCDlYqsm01Byc+YWSvxcAq+xpp3PhcK/AFNdPILtFpNd26ArNgWgWlr?= =?us-ascii?Q?lVjS7tbbMG+4rQtBZW8ZY4ep7odpujMip7iVFvNMGG4rHqm2ZItAWyp3WF7H?= =?us-ascii?Q?IQTGk9gSP8FYvPnwfb732IO2MRHacRRKnVKy9VlDQxgPT3memyAvLAVNMonn?= =?us-ascii?Q?VlumuU8LaN8kGK6aJV7/Au6myZ4OLLL9yV2S0RMv1Jt41lRhF8Bq2i+SKeOZ?= =?us-ascii?Q?oyH8HxvV1/0Z0aG1DgsGRKqpE3s8vSJqxY+N35iMxXyW54PUZ+vtK8xIUzGr?= =?us-ascii?Q?v8OhXgvGKiOBV4fEK84HDfWWiJGtkvYSmbCGX9TplJCTcCOm+SfS6Agr5OwJ?= =?us-ascii?Q?kMRMsN5OU68y8VUTNG1NV1o29H1b2WTXIiJzZqGgOnKXUqaKAsL6XvvvQdLY?= =?us-ascii?Q?1RR9Cd24NhPtFQmlmpzE1dj90JmnQGOCWyr7DSxKZkRTqbKT6unoXb1lc/9y?= =?us-ascii?Q?2nLFQbolK11oMi2dc8wE97gImsGdsIzkmR2CzizrKKOLgtXUYrOv9zLDII6F?= =?us-ascii?Q?EPzxJHfFuFvVjxFaa/Ph5ee4Sp8SwbFne3+xPw76lTeeJJM74t6wnyr2+c1Z?= =?us-ascii?Q?oMrjTuQFrc4E1UMJsQfcHEPAjlXvv5wb2k4bd2zN/kR78qUom3iMcYWid+FA?= =?us-ascii?Q?HzAVLTzvRl2CEVPupWNfueZ2/KpbAMwFU5QbHeQ5NrSaVlOYX2/FHtPp8Grw?= =?us-ascii?Q?VBCsM9Yl7EIxYXMqW0B74Xw9s/ydek440jDv2mgrQ8yzIwVkgAZbDClZcv2k?= =?us-ascii?Q?SdasRytK20bEkd8M74/JUpjLHN0aUdEl1sCqYSJWhf/0T?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 6:ACPnODQdrQnEkc1gEv2eeu5SfqbRu3M9jDhermKDL0O/37KBoDaxY4oqu7GF6EpKUV/ABSo8hrAU9uSD2ueR9SbzRA/FCUdq+2bVBeu5HTaWJfDjS3cr5ciXGwrIOhjovCxe5POLB7Xu59oCaKJK6exdaAk+gT7TTCQBjJVLtsR8Cgvkm4MaEp2BVKYbFeSm2c7BLQZHnr6hJTJVPg9uKNko3L25wu5rFSdQFmSN5yOOtCo1E7bsjU9vfKhViRJ8br7uZfgAgSUSEMJc0f7XBLA2qHeMD0J5VD3miwfvQHg=; 5:cr8uSYwUL1yo7TUk+SSlc7+uNdoXvecUruykndjoD5Q/ZsfWlTfHHmR4vn9lpRXjeoCd5yHARr5rViM0NiAwk72A3VKDuBrkVXWAwqmZG4QauFzCkfXO4QGjiJHCALL1sByMG6sazFwmdI2rSaZLhw==; 24:qcxujs2j6Idjtuoaje3TW5iWR6OYOxmc6cHXKAoLbxOK1ozNF1XRtoy+ExmtVu2k4ALWxuvnbhADmVqSRzddEqt7pSqJF1Xv/u5dqSX8y4Y=; 7:gCk+SmikvGOrDPLL82L9ypr89oXR/+B50LU3jih4OX2bTYHnyqpOmCrnCJ5VNesq2ocx5NbhkuBZsERNF5CHIa74V0ismvbp1DVtruE9Om6dQ93bn3scIgGIMTAC9VBxEZSyeZpB1oedcnWkSd0XKUmuPlcFmApbgnsLb3zK28MVUtR7f3D7A2XtKyozqh6zR5k5gN7Dek5XywdoGpQJyeKj9PU0Hsia+eot4/WoEtI4wPa2gpiVi7bUg1DOguC2 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 11:28:35.6018 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 11:28:40 -0000 On Tue, Sep 13, 2016 at 02:05:49PM +0000, ZELEZNIAK, ALEX wrote: > Idea here is not to allow VM to control policies assigned to it for security > and other reasons. PF is controlled by host and dictates what VM can and > can't do in regards of setting VF parameters. I think the proposed scheme, The VM does not take any action on its own. The VM will just follow what the centralized entity to do so. I think if you are planning to support different varieties of PMD then this could be an option.However, if you wish to support only a subset of PMDs then PF MBOX based scheme may be enough. In any case, I think exposing the fine details of PF/VF MBOX scheme in the ethdev spec is not a good idea. > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Tuesday, September 13, 2016 4:46 AM > > To: ZELEZNIAK, ALEX > > Cc: Bernard Iremonger ; > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > callback functions > > > > On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > > > Use case could be to inform application managing SRIOV about VM's > > intention > > > to modify parameters like add VLAN which might not be the one which is > > > assigned to VF or inform about VF reset and reapply settings like > > strip/insert > > > VLAN id based on policy. > > > > Is there any other way(more portable way) where we can realize the same > > use case? > > > > Something like, > > > > 1) The assigned VM operates/control the VF > > 2) A centralized entity post messages through UNIX socket or > > something(like vhost user communicates with VM). > > On message receive, VM can take necessary action on assigned VF. > > > > This will avoid the need of defining specifics of PF to VF mailbox > > communication in normative ethdev specification. > > > > And I guess it will work almost the PMD drivers as their is no > > PMD specific work here. > > > > Just a thought. > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Friday, September 09, 2016 10:11 AM > > > > To: Bernard Iremonger > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > > > ZELEZNIAK, ALEX > > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > > > callback functions > > > > > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > > > add _rte_eth_dev_callback_process_vf function. > > > > > add _rte_eth_dev_callback_process_generic function > > > > > > > > > > Adding a callback to the user application on VF to PF mailbox message, > > > > > allows passing information to the application controlling the PF > > > > > when a VF mailbox event message is received, such as VF reset. > > > > > > > > > > Signed-off-by: azelezniak > > > > > Signed-off-by: Bernard Iremonger > > > > > --- > > > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > > > lib/librte_ether/rte_ethdev.h | 61 > > > > ++++++++++++++++++++++++++++++++++ > > > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > > > 3 files changed, 85 insertions(+) > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > b/lib/librte_ether/rte_ethdev.c > > > > > index f62a9ec..1388ea3 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > @@ -2690,6 +2690,20 @@ void > > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > > enum rte_eth_event_type event) > > > > > { > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, NULL); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, param); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > struct rte_eth_dev_callback *cb_lst; > > > > > struct rte_eth_dev_callback dev_cb; > > > > > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > > > rte_eth_dev *dev, > > > > > continue; > > > > > dev_cb = *cb_lst; > > > > > cb_lst->active = 1; > > > > > + if (param != NULL) > > > > > + dev_cb.cb_arg = (void *) param; > > > > > + > > > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > > > dev_cb.cb_arg); > > > > > diff --git a/lib/librte_ether/rte_ethdev.h > > b/lib/librte_ether/rte_ethdev.h > > > > > index b0fe033..4fb0b9c 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.h > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > > > /**< queue state event (enabled/disabled) > > > > */ > > > > > RTE_ETH_EVENT_INTR_RESET, > > > > > /**< reset interrupt event, sent to VF on PF reset */ > > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > > > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > > > }; > > > > > > > > > > +/** > > > > > + * Response sent back to ixgbe driver from user app after callback > > > > > + */ > > > > > +enum rte_eth_mb_event_rsp { > > > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK > > > > */ > > > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and > > > > NACK */ > > > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request > > > > */ > > > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ > > > > > +}; > > > > > > > > Do we really need to define the specifics of PF to VF MBOX > > communication > > > > in normative ethdev specification? > > > > Each drivers may have different PF to VF MBOX definitions so it may not > > be > > > > very portable. > > > > What is the use-case here? If its for VF configuration, I think we can > > > > do it as separate 'sync' functions for each functionality so that > > > > PMDs will have room hiding the specifics on MBOX definitions. > > >