From: "Zende, Amruta S" <amruta.zende@intel.com>
To: "Iremonger, Bernard" <bernard.iremonger@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
Date: Mon, 7 Sep 2015 09:22:23 +0000 [thread overview]
Message-ID: <1574BF4E37E8634BA172E5CF34D31B5CEF7CD2@PGSMSX108.gar.corp.intel.com> (raw)
In-Reply-To: <8CEF83825BEC744B83065625E567D7C219F4A3F4@IRSMSX108.ger.corp.intel.com>
Certain functions like "rte_eth_dev_socket_id" assume the device to be a PCI device and access pointers like rte_eth_devices[port_id].pci_dev->numa_node.
Any such assumptions and dependencies should also be removed.
Thanks & regards,
Amruta Zende
+91-20-4305-2969
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Iremonger, Bernard
Sent: Thursday, September 3, 2015 7:33 PM
To: Thomas Monjalon; Neil Horman
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs
Hi Neil, Thomas,
> > <snip>
> >
> > > > You didn't remove the relationship of the ethdev to the pci
> > > > driver though, which is really the problem, An ethdev may reside
> > > > on any number of bus types (pci/usb/vmbus/virt/none).
> >
> > <snip>
> >
> > > > Whats really needed is a way to associate an ethdev with an
> > > > arbitrary bus
> >
> > <snip>
> >
> > > > > Please see email below from 6Wind
> > > > >
> > > > > http://dpdk.org/ml/archives/dev/2015-July/022107.html
> > > > >
> > > > I think you misread that. I think all Thomas is asking for
> > > > (correct me if I'm wrong Thomas), is for someone to start
> > > > refactoring the ethdev registration code so that we can have a
> > > > single init path without the need for wierd typing and
> > > > differentiation at
> init time.
> >
> > <snip >
> >
> > > > We just need to
> > > > start thinking about how to make bus registration independent of
> > > > ethernet device registration, and while your patch series sort
> > > > of eliminates some of that, its really not a proper refactoring
> > > > of the sort I think Thomas is asking for.
> >
> > I am just trying to distill what the actual requirement is from the
> > above
> discussion.
> >
> > (1) Remove relationship of the ethdev to the pci driver.
> Correct
I plan to continue work on the RFC to address this.
>
> > (2) Refactor ethdev registration code so that there is a single init path.
> Correct (or mostly correct, in rereading my initial post, there may be
> some ambiguitiy here)
>
> > (3) Make bus registration independent of ethdev registration.
> Correct
>
> > (4) Change all (17) PMD's to use the modified structures.
> >
> Correct (I assume the 17 number is accurate here)
There are 17 PMD directories some of which have multiple PMD's.
The total number of PMD's is 23 at present.
> > The rte_eal_driver_registration() code is in librte_eal, untouched
> > as yet by
> this patch set.
> >
> Correct, the code that registers an init function is a single path, which is great.
> However, that path requires that you specify a device type (in this
> case PMD_PDEV or PMD_VDEV to differentiate pci vs virtual devices (it
> uses this for ordering of initalization in rte_eal_dev_init, which is
> a hack). What would be preferred would be if the structure that was
> registered via that macro only held a name and an init routine to
> initalize the driver itself. Inside that init routine, the driver
> would then be responsible for registering with the appropriate bus
> type (virtual/pci/usb/whatever). A secondary function would be
> registered as part of that process (akin to the linux/bsd probe()
> method) which was called once for each instance of the device found on
> that bus.
>
I will send a second RFC to address the eal driver registration code issues in librte_eal.
> > The rte_eth_driver_registration() code is in librte_ether.
> > Should the pci fields be removed from the struct rte_eth_dev{} and
> > struct eth_driver{},
> IMO, yes, they should, as the driver can store pointers to those
> devices in their private per-device data area. That said, there may
> be value in including a union of all bus types in the ethdev itself,
> if there are higher layer functions that need to be aware of a given
> ethdevs bus type
I plan to park the issue of multiple bus types for now.
More consensus is needed on the best way forward.
>
> > and put somewhere else or replaced with a union of bus types and
> drivers?
Regards,
Bernard.
next prev parent reply other threads:[~2015-09-07 9:22 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <RFC PATCH>
2015-04-08 10:02 ` [dpdk-dev] [RFC PATCH] librte_pmd_ixgbe: changes to support PCI Port Hotplug Bernard Iremonger
2015-04-22 3:14 ` Qiu, Michael
2015-04-08 14:11 ` [dpdk-dev] [RFC PATCH] librte_pmd_e1000: igb and em1000 PCI Port Hotplug changes Bernard Iremonger
2015-04-30 13:16 ` [dpdk-dev] [RFC PATCH 1/1] librte_pmd_ring: changes to support PCI Port Hotplug Bernard Iremonger
2015-04-30 15:40 ` [dpdk-dev] [RFC PATCH 1/4] librte_pmd_i40e: " Bernard Iremonger
2015-04-30 15:41 ` [dpdk-dev] [RFC PATCH 2/4] librte_pmd_i40e: release vmdq vsi's in dev_close Bernard Iremonger
2015-04-30 15:42 ` [dpdk-dev] [RFC PATCH 3/4] librte_pmd_i40e: increase ASQ_DELAY_MS to 100 in i40evf_wait_cmd_done() Bernard Iremonger
2015-04-30 15:42 ` [dpdk-dev] [RFC PATCH 4/4] librte_pmd_i40e: call _clear_cmd() when error occurs Bernard Iremonger
2015-05-01 14:36 ` [dpdk-dev] [RFC PATCH] librte_pmd_bond: add support for PCI Port Hotplug Bernard Iremonger
2015-05-01 15:17 ` Neil Horman
2015-05-01 15:28 ` [dpdk-dev] [RFC PATCH] librte_pmd_virtio: " Bernard Iremonger
2015-05-05 14:36 ` [dpdk-dev] [RFC PATCH V2] librte_pmd_ring: changes to support " Bernard Iremonger
2015-05-06 16:15 ` Bruce Richardson
2015-05-06 10:22 ` [dpdk-dev] [RFC PATCH V2] librte_pmd_ixgbe: " Bernard Iremonger
2015-05-06 11:20 ` [dpdk-dev] [RFC PATCH V2] librte_pmd_e1000: igb and em1000 PCI Port Hotplug changes Bernard Iremonger
2015-05-27 16:00 ` [dpdk-dev] [RFC PATCH V2 1/2] drivers/net/virtio: add support for PCI Port Hotplug Bernard Iremonger
2015-05-27 16:00 ` [dpdk-dev] [RFC PATCH V2 2/2] drivers/net/virtio: check vq parameter Bernard Iremonger
2015-06-16 1:08 ` Ouyang, Changchun
2015-05-28 12:28 ` [dpdk-dev] [RFC PATCH V2] drivers/net/bonding: add support for PCI Port Hotplug Bernard Iremonger
2015-05-29 13:46 ` [dpdk-dev] [RFC PATCH V3] drivers/net/ring: changes to support " Bernard Iremonger
2015-06-03 15:21 ` Bruce Richardson
2015-06-02 10:18 ` [dpdk-dev] [RFC PATCH V3] ixgbe: " Bernard Iremonger
2015-06-03 14:03 ` [dpdk-dev] [RFC PATCH V3] e1000: igb and em1000 PCI Port Hotplug changes Bernard Iremonger
2015-06-04 16:24 ` [dpdk-dev] [RFC PATCH V2 1/4] i40e: changes to support PCI Port Hotplug Bernard Iremonger
2015-06-24 8:03 ` Qiu, Michael
2015-06-04 16:25 ` [dpdk-dev] [RFC PATCH V2 2/4] i40e: release vmdq vsi's in dev_close Bernard Iremonger
2015-06-04 16:25 ` [dpdk-dev] [RFC PATCH V2 3/4] i40e: increase ASQ_DELAY_MS to 100 in i40evf_wait_cmd_done() Bernard Iremonger
2015-06-04 16:26 ` [dpdk-dev] [RFC PATCH V2 4/4] i40e: call _clear_cmd() when error occurs Bernard Iremonger
2015-06-08 15:47 ` [dpdk-dev] [RFC PATCH V4] ixgbe: changes to support PCI Port Hotplug Bernard Iremonger
2015-06-15 22:31 ` Ananyev, Konstantin
2015-06-17 6:11 ` Zhang, Helin
2015-06-24 7:45 ` Qiu, Michael
2015-06-24 7:46 ` Qiu, Michael
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 0/5] PCI Port Hotplug changes Bernard Iremonger
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 1/5] i40e: changes to support PCI Port Hotplug Bernard Iremonger
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 2/5] i40e: release vmdq vsi's in dev_close Bernard Iremonger
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 3/5] i40e: increase ASQ_DELAY_MS to 100 in i40evf_wait_cmd_done() Bernard Iremonger
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 4/5] i40e: call _clear_cmd() when error occurs Bernard Iremonger
2015-06-10 8:27 ` [dpdk-dev] [RFC PATCH V3 5/5] i40e: clear queues in i40evf_dev_stop Bernard Iremonger
2015-06-10 12:09 ` [dpdk-dev] [RFC PATCH V4] e1000: igb and em1000 PCI Port Hotplug changes Bernard Iremonger
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs Bernard Iremonger
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 1/6] librte_ether: add fields from rte_pci_driver to rte_eth_dev and rte_eth_dev_data Bernard Iremonger
2015-08-31 14:07 ` Thomas Monjalon
2015-09-01 11:38 ` Iremonger, Bernard
2015-09-01 12:03 ` Bruce Richardson
2015-09-01 12:37 ` Ananyev, Konstantin
2015-09-01 12:43 ` Richardson, Bruce
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 2/6] librte_ether: handle RTE_ETH_DEV_INTR_LSC for vdevs Bernard Iremonger
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 3/6] null: remove pci device driver Bernard Iremonger
2015-08-31 14:11 ` Thomas Monjalon
2015-08-31 16:05 ` Iremonger, Bernard
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 4/6] ring: " Bernard Iremonger
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 5/6] bonding: " Bernard Iremonger
2015-08-27 17:48 ` Stephen Hemminger
2015-08-28 8:32 ` Iremonger, Bernard
2015-08-28 15:57 ` Stephen Hemminger
2015-08-27 15:40 ` [dpdk-dev] [RFC PATCH 6/6] pcap: " Bernard Iremonger
2015-08-27 17:43 ` [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs John W. Linville
2015-08-28 8:15 ` Iremonger, Bernard
2015-08-28 10:32 ` Neil Horman
2015-08-28 19:48 ` Wiles, Keith
2015-08-31 11:21 ` Iremonger, Bernard
2015-08-31 12:41 ` Neil Horman
2015-08-28 17:51 ` John W. Linville
2015-08-31 10:23 ` Iremonger, Bernard
2015-08-31 12:59 ` Neil Horman
2015-08-31 14:22 ` Thomas Monjalon
2015-09-01 13:38 ` Iremonger, Bernard
2015-09-01 19:18 ` Neil Horman
2015-09-03 14:02 ` Iremonger, Bernard
2015-09-07 9:22 ` Zende, Amruta S [this message]
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 00/18] refactor eal driver registration code Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 01/18] librte_eal: remove type field from rte_driver structure Bernard Iremonger
2015-09-04 13:08 ` Thomas Monjalon
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 02/18] af_packet: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 03/18] bnx2x: remove type field and initialise name field in " Bernard Iremonger
2015-09-04 11:26 ` Harish Patil
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 04/18] bonding: remove type field from " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 05/18] cxgbe: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 06/18] e1000: remove type field and initialise name field in rte_driver structures Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 07/18] enic: remove type field and initialise name field in rte_driver structure Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 08/18] fm10k: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 09/18] i40e: remove type field and initialise name field in rte_driver structures Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 10/18] ixgbe: remove type field and initialise name field in rte_driver structure Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 11/18] mlx4: remove type field from " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 12/18] mpipe: remove type field and update name in " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 13/18] null: remove type field from " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 14/18] pcap: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 15/18] ring: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 16/18] virtio_ethdev: remove type field and initialise name field in " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 17/18] vmxnet3: " Bernard Iremonger
2015-09-04 11:01 ` [dpdk-dev] [RFC PATCH 18/18] xenvirt: remove type field from " Bernard Iremonger
2015-09-04 11:18 ` [dpdk-dev] [RFC PATCH 00/18] refactor eal driver registration code Bruce Richardson
2015-09-04 12:46 ` Iremonger, Bernard
2015-09-04 12:53 ` Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1574BF4E37E8634BA172E5CF34D31B5CEF7CD2@PGSMSX108.gar.corp.intel.com \
--to=amruta.zende@intel.com \
--cc=bernard.iremonger@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).