On 4/3/2018 10:06 AM, David Marchand wrote: > On Mon, Apr 2, 2018 at 6:13 PM, santosh > <santosh.shu...@caviumnetworks.com> wrote: >> On Friday 30 March 2018 08:59 PM, David Marchand wrote: >>> I can see we enforce the driver name by putting it after the call to >>> .dev_infos_get. >>> http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n2399 >>> >>> octeontx pmd seems to try to do something about it: >>> http://dpdk.org/browse/dpdk/tree/drivers/net/octeontx/octeontx_ethdev.c#n622 >>> >>> Not sure it does something, might be a thing to cleanup. >>> >>> >> In case, if your referring to driver_name update then >> indeed its a cleanup [1]. >> >> Otherwise, I don't see any issue with v4 Or >> may be /I /misunderstood your comment. > > I agree there is no fundamental issue. > > dev_info->device = dev->device; > > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); > (*dev->dev_ops->dev_infos_get)(dev, dev_info); > dev_info->driver_name = dev->device->driver->name; > > If somebody (I mean some pmd out there) has a usecase with > dev_info->device != dev->device, why not.
Intentional let drivers update this variable although I don't also see any use case of it. This variable was set by PMDs before this patch, so I don't see any reason to be so strict here. If driver does anything ethdev will set dev_info->device for it, if it want to overwrite, for any reason, it will have the capability. > > Thomas ? > >
