From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id EF4C5558F for ; Thu, 6 Oct 2016 17:33:01 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 06 Oct 2016 08:32:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,454,1473145200"; d="scan'208";a="1066995816" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga002.fm.intel.com with ESMTP; 06 Oct 2016 08:32:38 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.164]) by IRSMSX107.ger.corp.intel.com ([169.254.10.95]) with mapi id 14.03.0248.002; Thu, 6 Oct 2016 16:32:36 +0100 From: "Iremonger, Bernard" To: Thomas Monjalon CC: "dev@dpdk.org" , "Shah, Rahul R" , "Lu, Wenzhuo" , "az5157@att.com" , "jerin.jacob@caviumnetworks.com" Thread-Topic: [dpdk-dev] [PATCH v5 01/13] librte_ether: modify internal callback function Thread-Index: AQHSH8SD2FeiVD24+EqwRkAkHVUdGaCbUbEAgAAo32D///jLgIAAGA+w Date: Thu, 6 Oct 2016 15:32:35 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C21A08F8EF@IRSMSX108.ger.corp.intel.com> References: <1475592734-22355-1-git-send-email-bernard.iremonger@intel.com> <8021250.9Wl94qBdaq@xps13> <8CEF83825BEC744B83065625E567D7C21A08F83F@IRSMSX108.ger.corp.intel.com> <1884200.vdWHEKFaxn@xps13> In-Reply-To: <1884200.vdWHEKFaxn@xps13> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTY3ZTlhYmYtNjMyNC00YmM1LWJkOTYtYjQ0ZTZjNTFhOGRlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFETHRmTlZ3ZEV4QjZxc3hGc2p5UTlaUGc5eTRodnBFXC9KaW9Zem1SWnRjPSJ9 x-ctpclassification: CTP_IC 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 v5 01/13] librte_ether: modify internal callback function 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: Thu, 06 Oct 2016 15:33:02 -0000 Hi Thomas, > > > Subject: Re: [dpdk-dev] [PATCH v5 01/13] librte_ether: modify > > > internal callback function > > > > > > 2016-10-06 12:26, Bernard Iremonger: > > > > void > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > - enum rte_eth_event_type event) > > > > + enum rte_eth_event_type event, void *param) > > > > > > You need to squash the patches updating the calls to this function. > > > Otherwise, this patch does not compile. > > > > I will have to squash everything into one patch, separate patches will = not > compile. >=20 > No you can keep a separate patch for the VF event in ixgbe. I have 4 patches at present librte_ether net/ixgbe drivers/net app/test Would this be acceptable or do you just want everything squashed into libr= te_ether except for net/ixgbe? =20 =20 > > > [...] > > > > + if (param !=3D NULL) > > > > + dev_cb.cb_arg =3D (void *) param; > > > > > > You are overriding the user parameter. > > > > Yes, we want to update the user parameter for the > > RTE_ETH_EVENT_VF_MBOX I have renamed param to cb_arg to make it clearer what is happening. > > > As it is only for a new event, it can be described in the register > > > API that the user param won't be returned for this event. > > > > I will add a description in the rte_eth_dev_callback_register function= . > > > > > But a better design would be to add a new parameter to the callback. > > > However it will be an API breakage. > > > > I do not want to break the ABI at this point. >=20 > Yes, but it can be considered for a later change. Yes, ok =20 > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > > > > > > Sorry I do not parse well this line. > > > The event name is VF_MBOX and the comment is about the callback > > > processing this event on PF side? > > > I would suggest this kind of comment: "message from VF received by PF= " > > > > Ok. > > > > > > > > [...] > > > > * Pointer to struct rte_eth_dev. > > > > * @param event > > > > * Eth device interrupt event type. > > > > + * @param param > > > > + * Parameter to pass back to user application. > > > > + * Allows the user application to decide if a particular > > > > + function > > > > + * is permitted. > > > > > > In a more generic case, the parameter gives some details about the > event. >=20 > Please consider a rewording here, thanks. =20 I have reworded here, I hope it is clearer. Regards, Bernard.