Re: [lng-odp] driver interface thinkings....

On 11/09 09:42:49, Francois Ozog wrote: > To deal with drivers we need to have additional "standard" (helper or API?) > objects to deal with MAC addresses. > > ODP could be made to handle SDH, SDLC, FrameRelay or ATM packets. A > packet_io is pretty generic... > > But as soon as we talk with

Re: [lng-odp] driver interface thinkings....

To deal with drivers we need to have additional "standard" (helper or API?) objects to deal with MAC addresses. ODP could be made to handle SDH, SDLC, FrameRelay or ATM packets. A packet_io is pretty generic... But as soon as we talk with drivers and initialization, we need to deal with L1

Re: [lng-odp] driver interface thinkings....

On 9 November 2016 at 09:09, Christophe Milard wrote: > > > On 8 November 2016 at 18:19, Francois Ozog > wrote: > >> Hi Christophe, >> >> We are focusing on network devices which have at least network ports. >> Inventory of devices and

Re: [lng-odp] driver interface thinkings....

On 8 November 2016 at 18:19, Francois Ozog wrote: > Hi Christophe, > > We are focusing on network devices which have at least network ports. > Inventory of devices and ports are two distinct topics as there is no > guarantee that there is one device per port. (Intel and

Re: [lng-odp] driver interface thinkings....

Hi Christophe, We are focusing on network devices which have at least network ports. Inventory of devices and ports are two distinct topics as there is no guarantee that there is one device per port. (Intel and Mellanox have this policy: one device per PCI port, but many others have one PCI

[lng-odp] driver interface thinkings....

Bonsoir Francois, I'll take that in English thereafter so that other can read (copy to the list). I have looked at that: https://dpdksummit.com/Archive/pdf/2016Userspace/Day02-Session03-ShreyanshJain-Userspace2016.pdf I guess that is what you referred to, Francois, when talking at the SYNC