2016-12-16 12:15, Stephen Hemminger:
> On Fri, 16 Dec 2016 19:09:02 +0100
> Thomas Monjalon wrote:
>
> > 2016-12-15 09:26, Stephen Hemminger:
> > > On Thu, 15 Dec 2016 12:19:44 +0530
> > > Shreyansh Jain wrote:
> > > > It is not a scale-able model where we have to change eth_driver/eth_dev
>
On Fri, 16 Dec 2016 19:09:02 +0100
Thomas Monjalon wrote:
> 2016-12-15 09:26, Stephen Hemminger:
> > On Thu, 15 Dec 2016 12:19:44 +0530
> > Shreyansh Jain wrote:
> > > It is not a scale-able model where we have to change eth_driver/eth_dev
> > > for every new device type, other than PCI. Mayb
2016-12-15 09:26, Stephen Hemminger:
> On Thu, 15 Dec 2016 12:19:44 +0530
> Shreyansh Jain wrote:
> > It is not a scale-able model where we have to change eth_driver/eth_dev
> > for every new device type, other than PCI. Maybe VMBus is _very_ close
> > to PCI so no changes are required in PCI la
On Thu, 15 Dec 2016 12:19:44 +0530
Shreyansh Jain wrote:
> > @@ -1866,7 +1871,11 @@ typedef int (*eth_dev_uninit_t)(struct rte_eth_dev
> > *eth_dev);
> > * - The size of the private data to allocate for each matching device.
> > */
> > struct eth_driver {
> > - struct rte_pci_driver pci_d
On Thursday 15 December 2016 05:29 AM, Stephen Hemminger wrote:
Generalize existing bus support to handle VMBUS in Hyper-V.
Most of the code is based of existing model for PCI, the difference
is how bus is represented in sysfs and how addressing works.
This is based on earlier code contributed b
5 matches
Mail list logo
