From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) by dpdk.org (Postfix) with ESMTP id 0EB53379B for ; Tue, 5 Jul 2016 07:16:32 +0200 (CEST) Received: from [127.0.0.1] (ip-37-188-129-152.eurotel.cz [37.188.129.152]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 3rkBv26v3qzhS; Tue, 5 Jul 2016 07:16:30 +0200 (CEST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160705051630.5861459.88497.5797@rehivetech.com> Date: Tue, 05 Jul 2016 07:16:30 +0200 From: Jan Viktorin In-Reply-To: <577B3ABE.4040709@nxp.com> References: <1462542490-15556-1-git-send-email-viktorin@rehivetech.com> <1462542490-15556-29-git-send-email-viktorin@rehivetech.com> <577397EF.2080300@nxp.com> <20160704150451.1a61fbbd@pcviktorin.fit.vutbr.cz> <577A7245.700@nxp.com> <20160704163646.45d1f0f8@pcviktorin.fit.vutbr.cz> <577B3ABE.4040709@nxp.com> To: Shreyansh jain Cc: dev@dpdk.org, Thomas Monjalon Subject: Re: [dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver 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: Tue, 05 Jul 2016 05:16:32 -0000 Hello Shreyansh, =E2=80=8E > On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote: >> On Mon, 4 Jul 2016 19:57:18 +0530 >> Shreyansh jain wrote: >>=20 >> [...] >>=20 >>>>>> @@ -1431,7 +1524,7 @@ >rte_eth_dev_info_get(uint8_t port_id, struct = >rte_eth_dev_info *dev_info) >>>>>>=20 >>>>>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->>dev_infos_get); >>>>>> (*dev->dev_ops->dev_infos_get)(dev, dev_info); >>>>>> - dev_info->pci_dev =3D dev->pci_dev; >>>>>> + dev_info->soc_dev =3D dev->soc_dev;=20 >>>>> >>>>> I think both the members, pci_dev and soc_dev, should be updated by t= his call. >>>>> Is there some specific reason why soc_dev is the only one which is ge= tting updated?=20 >>>> >>>> Yes, looks like a mistake. Thanks! And sorry for delayed reply.=20 >>> >>> No problems - thanks for confirmation. >>> I have gone through almost complete series and as and when you rebase i= t, it would have my ACK. >>=20 >> OK, thanks. That's what I am playing with right now. I've rebased on v3 = of this patch. There will >> be some more tests in my v2. >>=20 >>> rte_driver patchset which I sent last are broken - I will publish an up= dated version very soon. >>=20 >> I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... A= re you sure about this step? >> I wrote that I'll change it myself for v2 for SoC to accept name and poi= nter as it was originally for PCI... > > Really? Then probably I understood it wrong. I don't have any issues with= the first one as well but just for slightly cleaner approach I thought of = going with your suggest (or, suggestion as understood by me). =E2=80=8E> > Anyways the patch is broken and doesn't apply on master. I will push a ne= w version (with revert EAL_PCI_REGISTER arguments) within today. Ok. I am away for few days this week but I will continue as soon as possibl= e on the soc patchset and also on the rte_device/driver issue. We have to c= ut this as soon as possible. I think the best would be to post a small patc= hset on top of this one introducing the change. I think, there should be a single list of rte_device and a list for rte_dri= ver while preserving lists for each infra, so also rte_pci_device would hav= e a separate list. Then, it's possible to iterate over all PCI devices easi= ly and iterate over all devices generically at the same time. What I am not sure about are addr and id things. It's quite difficult to ge= neralize them. The addr needs a conpare function but how to compare pci add= r to another type of addr? Do we need this? If so, I'll work on this. Another thing - resources. Do we want to have a kind of a generic rte_resou= rce instead of rte_pci_resource? I think this is clearly possible. I am abo= ut to do this. I am afraid we are unable to change devargs significantly in this release := / (due to time and lack of a discussion here).=E2=80=8E=C2=A0What I really = like to see is the virtual device conversion and pmd_type removal. Are you = able to look at this? Any other objections? Jan Viktorin RehiveTech Sent from a mobile device=E2=80=8E >>=20 >> Jan >>=C2=A0 > >- >Shreyansh