[lng-odp] Fwd: [dpdk-dev] Invitation to comment on Virtual I/O Device (VIRTIO) Version 1.1 - ends February 21st

THis is certainly relevant to ODP... Cheers -- Forwarded message - From: Paul Knight Date: Mon, 28 Jan 2019 at 03:11 Subject: [dpdk-dev] Invitation to comment on Virtual I/O Device (VIRTIO) Version 1.1 - ends February 21st To: , , OASIS TAB , , <

Re: [lng-odp] v1.20.0.0 has been released

Thanks Maxim. FF On Tue, 4 Dec 2018 at 16:54, Maxim Uvarov wrote: > v1.20.0.0 has been released and api-next branch is rebased on top of it. > > == OpenDataPlane (1.20.0.0) > === Summary of Changes > ODP v1.20.0.0 is a refresh of ODP, incorporating significant > configurability > and

Re: [lng-odp] Flow aware scheduler enhancement for ODP

In the case of DPI, I came across this. Did you consider : - a symetric hash option so that uplink and downlink packets of a single flow (either TCP or UDP) give the same hash value? - an offset so that HW calculates the hash starting at a specific packet area? - an option that would calculate

Re: [lng-odp] IPsec and crypto performance and OpenSSL

I favor finishing ODP (ex 2.0) integration rather than optimizing linux-generic at this stage. On 11 December 2017 at 14:39, Peltonen, Janne (Nokia - FI/Espoo) < janne.pelto...@nokia.com> wrote: > Hi, > > When playing with IPsec I noticed that the Linux generic > ODP implementation creates a

Re: [lng-odp] New API to convert user area ptr to odp_packet_t

t; achieve 10Gb line rate under the best of circumstances, which means > something more fundamental is going on that needs to be understood first. > > > > On Sat, Dec 9, 2017 at 6:53 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> I'd like to have

Re: [lng-odp] New API to convert user area ptr to odp_packet_t

I'd like to have SoC vendors feedback on the discussion and on the following: This ODP user area is used by VPP to put a vlib_buffer information. VPP is just one of the applications that will use this simple mechanism and that is certainly a design pattern. A user area can exist when an odp

[lng-odp] VPP and ODP webinar: Event Registration 9am 11/30 PT

Dear all, You may be interested to register for a webinar 9-10am tomorrow Thursday PT. https://event.on24.com/eventRegistration/EventLobbyServlet?target= reg20.jsp=speaker=1539471=1= 58BAA4CAC57783D388386F55C1585A0D®Tag==register Bob Monkman and Bill Fischofer will give a presentation on

Re: [lng-odp] issues with usage of mellanox 100G NICs with ODP & ODP-DPDK

ODP2.0 should allow ODP to leverage directly libiverbs from a native ODP pktio without DPDK layer. Mellanox has created a userland framework based on libiverbs while we try to promote an extension of Mediated Device (vfio-mdev). FF On 9 November 2017 at 14:18, Maxim Uvarov

Re: [lng-odp] DDF discussions taking time

queues. But this classifier may not forward to Port C of another SmartNIC. So information about devices and their structures will be required. That is the role of the DDF. FF FF On 28 October 2017 at 00:01, Bill Fischofer <bill.fischo...@linaro.org> wrote: > > > On Fri, Oct 27, 2017 at

Re: [lng-odp] net-mdev and user space drivers

Le lun. 30 oct. 2017 à 22:23, Bill Fischofer a écrit : > On Mon, Oct 30, 2017 at 2:54 PM, Honnappa Nagarahalli < > honnappa.nagaraha...@linaro.org> wrote: > > > Bill mentioned that the packets are flying through net-mdev, good news :) > > > > I mentioned that Ilias and

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:54, Francois Ozog <francois.o...@linaro.org> a écrit : > Le ven. 27 oct. 2017 à 23:51, Bill Fischofer <bill.fischo...@linaro.org> > a écrit : > >> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog <francois.o...@linaro.org> >> wrote:

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:51, Bill Fischofer <bill.fischo...@linaro.org> a écrit : > On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> >> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli < >> honnappa.nagaraha...@

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit : > On 27 October 2017 at 13:35, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > >> >> >> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <francois.o...@li

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 20:35, Bill Fischofer <bill.fischo...@linaro.org> a écrit : > On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> >> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer <bill.fischo...@linaro.org> >&g

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 17:31, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit : > On 27 October 2017 at 02:36, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Well, we do not need to scan all the platform because the pktio_open >> cont

Re: [lng-odp] DDF discussions taking time

rm during initialization. In the current packet I/O framework, all >> the function pointers of the driver are known before odp_pktio_open API is >> called. If we have to stick to this design, the drivers for the PCI device >> should have registered their functions with the packet

Re: [lng-odp] Relation between Enumerator class and Enumerator

(i.e. map it > to user space) then you can link pci number with that driver which will > get netmdev and create dummy net device for it. > In that case this can be only a VFIO-pci "all userspace" driver . If no kernel driver you can't use netmdev (by definition: only a driver for

Re: [lng-odp] Relation between Enumerator class and Enumerator

In the case of netmdev the device is still there. Please check with Ilias for detailed behavior of this technology FF Le ven. 27 oct. 2017 à 10:29, Jianbo Liu a écrit : > The 10/27/2017 10:25, Maxim Uvarov wrote: > > yes, discovery is done by other tools like lspci, /proc

Re: [lng-odp] Relation between Enumerator class and Enumerator

This should not be limited to pci . The good news is that with netmdev you start with /sys/class/net and can find what you need. Actually you even do NOT need pci pus information from /sys/bus/pci because netmdev provides what you need in a bus independent manner. FF Le ven. 27 oct. 2017 à

[lng-odp] Fwd: SDxCentral Needs Your Input - 2017 Open Source in Networking Survey

Hi, you probably already received this invitation directly, but I think this is an opportunity to illustrate ODP concrete usages. If your company policies allow responding to the survey, please do. Cordially, François-Frédéric -- Forwarded message -- From: SDxCentral

Re: [lng-odp] DDF discussions taking time

Well, we do not need to scan all the platform because the pktio_open contains enough information to target the right device. This is almost true as we need to have an additional "selector" for the port on multiport NICs that are controlled by a single pci ID. :: or something like that. All ports

Re: [lng-odp] odp api to query free/tottal ram

October 2017 at 22:01, Bill Fischofer <bill.fischo...@linaro.org> wrote: > On Mon, Oct 23, 2017 at 2:22 PM, Maxim Uvarov <maxim.uva...@linaro.org> > wrote: > > > On 10/23/17 18:23, Francois Ozog wrote: > > > Hi Maxim, > > > > > > Is this regula

Re: [lng-odp] odp api to query free/tottal ram

Hi Maxim, Is this regular memory or DMA capable memory? This would mean application would know how, for instance, to handle things when memory is lower than a threshold or something similar; or it may decide to use a percentage of memory for packet pools; or many other policies. I don't see

Re: [lng-odp] generic core + HW specific drivers

Hi Petri, DPDK modules are not allowing DPDK to adapt to underlying architecture. It is just pugable HW. The DDF will deal with that. The problem we need to solve is architecture adaptation. where the CORE of the application changes. there is a single DPDK core with drivers. ODP has different

Re: [lng-odp] generic core + HW specific drivers

Hi Bogdan, cloud manager is a loosely defined entity ;-) In the context of NFV orchestration will not deal with this. VNF manager may but there is lack of "sensing" information. If you think of an AWS/Azure image, then this simply does not work. FF On 4 October 2017 at 15:27, Bogdan Pricope

Re: [lng-odp] generic core + HW specific drivers

Hi Ilias, there are two mechanisms: - modular framework - DDF Modular framework will be used to adapt to SoC platform. DDF will be used to adapt to pugable NICs So I guess you were referring to plugable NICs. FF On 4 October 2017 at 14:35, Ilias Apalodimas

Re: [lng-odp] generic core + HW specific drivers

I would leave it tu SoC vendors that can define a reliable and sustainable method... Le mar. 3 oct. 2017 à 22:26, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit : > On 3 October 2017 at 08:51, Francois Ozog <francois.o...@linaro.org> > wrote: > > Hi Maxim

Re: [lng-odp] generic core + HW specific drivers

ople review current cloud-dev > branch work); > - at least several platforms are merged together with that framework to > show it's effectiveness; > > In my understanding if all 4 items are met nobody will have objections. > > Other thing is might be shift priorities a little

Re: [lng-odp] generic core + HW specific drivers

Thanks Ola and Petri. Let's talk about use cases first. Go to market for ODP applications may be: - A product composed of software and hardware (typically a NEP approach such as Nokia) - A software to be installed by a system administrator of an enterprise - A "service" to be part

Re: [lng-odp] Modular Pkt I/O - Status

Thanks Honnappa. Following a discussion I heard on a recent arch call, I take the opportunity to re-state in black on white: - there are and continue to be SoC specific ODP implementations that leverage little code from Linux Generic. There has been a request to the steering committee (initially

Re: [lng-odp] DPDK integration under DDF

I'd like we sync up on key elements of the document at the arch call today. I'd like to restate a few things: - ODP Cloud single binary should support multiple hardware environments through DDF - ODP and ODP applications should accommodate how HW uses memory on the receive side, not the oppsoite

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

I think I do now. So antoher question: from device memory to host memory, is it a DMA transfer for some other SoC specific technology? Cordially, FF On 15 June 2017 at 17:58, Bala Manoharan <bala.manoha...@linaro.org> wrote: > > On 15 June 2017 at 20:00, Francois Ozog

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

I wonder then how packet receive in HW driven packet buffers is handled, may be with device memory Can you explain the cases of packet receive with ODP application supplied (through packetio open) mempools? FF On 15 June 2017 at 15:42, Bala Manoharan wrote: >

Re: [lng-odp] My last day at linaro/LNG

Hi Christophe, It is a big loss for LNG. On the technical side you have both conceptual talent and great implementation skills. This is not so common and DDF was a challenge at your "measure" (as a French you will know what I mean as I don't know if it translates well in English). Despite all

Re: [lng-odp] 32b support in ODP-Cloud

t;> > >> >> On 27 March 2017 at 08:36, Ola Liljedahl <ola.liljed...@linaro.org> > >> >> wrote: > >> >> > On 27 March 2017 at 07:58, Honnappa Nagarahalli > >> >> > <honnappa.nagaraha...@linaro.org> wrote: > >> &g

Re: [lng-odp] 32b support in ODP-Cloud

The more I dig the less I understand ;-) Let me ask a few questions: - in the future, when selling 32 bit silicon, which architecture version will it be ARMv7 or ARMv8 ? - is the target solution will be running ALL in 32 bits? (boot in 32 bits, Linux 32 bits, 32 bits apps)? - or is the target

Re: [lng-odp] Generic handle in ODP

t; > > > Thanks everyone for your time. > > > > *From:* Francois Ozog [mailto:francois.o...@linaro.org] > *Sent:* 02 March 2017 14:44 > *To:* Verma, Shally <shally.ve...@cavium.com> > *Cc:* Maxim Uvarov <maxim.uva...@linaro.org>; lng-odp@lists.linaro.org > &

Re: [lng-odp] Generic handle in ODP

n example to explain use case. > >> > >> packet APIs are good for interface which always and only process data > >> of type odp_packet_t however if anyone would want to extend same API > >> to support plain buffer type memory as well (thus avoiding > >>

Re: [lng-odp] Generic handle in ODP

t; nokia-bell-labs.com] > Sent: 01 March 2017 14:38 > To: Verma, Shally <shally.ve...@cavium.com>; Francois Ozog < > francois.o...@linaro.org> > Cc: lng-odp@lists.linaro.org > Subject: RE: [lng-odp] Generic handle in ODP > > > > > -Original Message---

Re: [lng-odp] Generic handle in ODP

Hi Shally, I am unsure this leads to a safe direction and here is why. Depending on the hardware, software provides either 1) a bunch of buffers where the HW will place packets (1 buffer will receive one packet) or 2) a large memory zone in which the hardware will place the packets according to

Re: [lng-odp] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement reference apis

g. > race conditions are found. > > -Petri > > > > -Original Message- > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Bill > > Fischofer > > Sent: Saturday, February 18, 2017 6:28 PM > > To: Francois Ozog <francoi

Re: [lng-odp] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement reference apis

Well, problem is still there. You are doing something on a packet that may not exist anymore. On 17 February 2017 at 22:08, Bill Fischofer wrote: > I've posted patch http://patches.opendataplane.org/patch/8155/ to > address this issue. It goes on api-next on top of

Re: [lng-odp] [API-NEXT PATCHv4 2/4] linux-generic: timer: implement odp_timer_capability()

I think this is quite useful for cloud applications that do not know the underlying hardware specs and need to check what is effectively possible. "hardware" resolution is nothing without all surrounding software layers, and virtualization in particular... On 17 February 2017 at 09:43, Kevin Wang

Re: [lng-odp] Why do not odp use a multi-process model?

Hi, I'd like to complement Christophe's answers. Today, Linaro produces an ***API*** and a reference implementation so that silicon vendors can produce high performance, production grade ODP on their platform. So I would encourage you to use the version that is compatible with your hardware

Re: [lng-odp] [RFC] ODP classification matching rules extensions

can also be > realized in SW. That would provide a generic means of having a unified > parser/classification strategy that is portable across all platforms, in > keeping with ODP's design goals. > > On Tue, Feb 14, 2017 at 11:29 AM, Francois Ozog <francois.o...@linaro.org>

Re: [lng-odp] measuring time and/or cycles

Thanks for taking the lead ;-) I fully agree on deprecating cpu cycles API in ODP. Better use a true PMU profiling API: we will not be able to upstream a special driver and if we have to spend engineering resources, better off on ODP itself. FF On 14 February 2017 at 19:37, Brian Brooks

[lng-odp] [RFC] ODP classification matching rules extensions

Hi, as I was checking ODP Classification rules, I spotted a few possible extensions: - global options: . apply the defined rule on the last IP header - additional rules . rule on SCTP port . rule on IPsec SPI . rule on GTP TEID Can those extensions be implemented by current hardware

Re: [lng-odp] 32-bit support in examples

The kernel has used a set of spinlocks to help dealing with atomics in certain conditions (architecture, length of bitfield...). A discussion on what atomi operations are needed may be of value to ODP too: https://lwn.net/Articles/695257/ On 23 January 2017 at 10:49, Joe Savage

Re: [lng-odp] 32-bit support in examples

well, yes. But that is the only atomic operation supported. No add, sub, inc, xadd, bit operations Le ven. 20 janv. 2017 à 14:31, Joe Savage a écrit : > > I wonder what processor supports 128 bits atomics. As far as I know Intel > > > does not support it. Lock prefix is

Re: [lng-odp] 32-bit support in examples

I wonder what processor supports 128 bits atomics. As far as I know Intel does not support it. Lock prefix is not allowed on SSE instructions. FF Le ven. 20 janv. 2017 à 13:59, Joe Savage a écrit : > > Unfortunately, ODP atomics API does not support 128 bit atomics - at >

Re: [lng-odp] register_notifier

at should be done on HW removal: do we expect enumerators to > "disregister"/ be removed. I am assuming a case where we have device > dependant enumerator > > Christophe. > > On 5 January 2017 at 11:43, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Hi

Re: [lng-odp] register_notifier

Hi Christophe, event are not just "new device" (in that case I would agree with you). Events can be: - "attention" (before "poweroff") for a specific device to orderly shutdown before poweroff (or remove if virtio-net device in a VM). - SFP insertion/removal of a specific port - Error condition

Re: [lng-odp] api for small buffer allocations

all tomorrow, Francois? Maybe a topic to take > then... > > Christophe. > > On 2 January 2017 at 17:48, Francois Ozog <francois.o...@linaro.org> wrote: >> Sorry for joining the discussion late... >> >> here are a few points: >> >> The more we defer taking into account NU

Re: [lng-odp] api for small buffer allocations

Sorry for joining the discussion late... here are a few points: The more we defer taking into account NUMA node in memory related APIs, the more we'll suffer when we'll be forced to integrate it. I would strongly suggest we address this topic now. Petri mentioned that we could do allocations on

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

then > specify the dev name string format, etc later on, but it would not change > the API if a timer is called “timer0” or “timer0:2” or > “/proc/soc/0/timer/1” or something else. > > > > -Petri > > > > > > > > *From:* Francois Ozog [mailto:francois

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

For the link, I think it ate the following it. Here it is without decoration: http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf On 6 December 2016 at 16:05, Francois Ozog <francois.o...@linaro.org> wrote: > OK.

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

e a more comprehensive approach based on their capabilities which can > then be generalized. BTW, your link doesn't resolve. Typo somewhere? > > On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Devicetree has been formed by a

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

; On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Hi Bill, >> >> could you clarify if this "device" is related to devicetree as defined by >> Linaro (https://github.com/devicetree-org/devicetree-specification)

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

Hi Bill, could you clarify if this "device" is related to devicetree as defined by Linaro (https://github.com/devicetree-org/devicetree-specification) or the devices that are in the scope of Christophe Millard, or some other device concept ? FF On 6 December 2016 at 04:43, Bill Fischofer

Re: [lng-odp] Driver registration: object version control

additional API related to device management and not "packetio" related: https://lwn.net/Articles/677967/ FF On 29 November 2016 at 20:35, Christophe Milard < christophe.mil...@linaro.org> wrote: > > > On 29 November 2016 at 20:00, Francois Ozog <franc

Re: [lng-odp] Driver registration: object version control

On 29 November 2016 at 19:03, Christophe Milard < christophe.mil...@linaro.org> wrote: > > > On 29 November 2016 at 18:13, Francois Ozog <francois.o...@linaro.org> > wrote: > >> >> >> On 29 November 2016 at 16:44, Christophe Milard < >> chr

Re: [lng-odp] Driver registration: object version control

On 29 November 2016 at 16:44, Christophe Milard < christophe.mil...@linaro.org> wrote: > > > On 29 November 2016 at 13:22, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Hi, >> >> comments inline >> >> On 29 November 2016 at 1

Re: [lng-odp] Driver registration: object version control

Hi, comments inline On 29 November 2016 at 10:58, Christophe Milard < christophe.mil...@linaro.org> wrote: > Hi, > > In our last meeting, yesterday, we agreed on the following objects: > 1) enumerator class > 2) enumerator > 3) enumerated_device > 4) devio > [FF] we have defined two types of

Re: [lng-odp] enumerator and driver registration

Hello, I made a google doc version of this to simplify comments and resolving. https://docs.google.com/a/linaro.org/document/d/10gS9wPNza-EXfxu9iVdk6o7- cfhUz2XJ2dp50t0ERas/edit?usp=sharing (I gave edit rights to Christophe, Forest and Yi: you should you PrettyCode addon for syntax

Re: [lng-odp] virtio and vhost support in ODP

> Hi Francois > > > From: Francois Ozog [mailto:francois.o...@linaro.org] > > Sent: Wednesday, November 16, 2016 13:42 > > To: Christophe Milard > > Cc: Yehuda Yitschak; Shadi Ammouri; lng-odp@lists.linaro.org > > Subject: Re: [lng-odp] virtio and vhost

Re: [lng-odp] [API-NEXT PATCHv2 3/5] api: init: driver load function added

river loading, > right? (of course on linux one could receive an event on directory write...) > > In dpdk, many drivers come with dpdk. Possibly we could do that too, and > that could reduce the usage on the driver_load function... > > Christophe > > > > On 16 November 20

Re: [lng-odp] [API-NEXT PATCHv2 3/5] api: init: driver load function added

saying that we go for a predefined list of driver only? > > So drivers have to be .so files (because of autotools), but we don't give > the possibility to load a free driver?? > > Christophe > > On 16 November 2016 at 11:45, Francois Ozog <francois.o...@linaro.org>

Re: [lng-odp] [API-NEXT PATCHv2 3/5] api: init: driver load function added

Hello, If the north API is the one visible by ODP applications then I don't think it is a good idea to expose that. DPDK exposed it at the beginning and is now internal. That said there must be a standard way to manage drivers fir the benefit of the device framework. I don't think the idea of

Re: [lng-odp] virtio and vhost support in ODP

If I may complement Christophe answer: the target is to have ODP being able to leverage virtio-net in the VM directly. Today, ODP can make use of virtio-net in a VM through DPDK packet io using ODP-DPDK. Accessing virtio-net device directly from ODP require both a device framework and a driver

Re: [lng-odp] continuous memory allocation for drivers

On 11 November 2016 at 10:10, Brian Brooks wrote: > On 11/10 18:52:49, Christophe Milard wrote: > > Hi, > > > > My hope was that packet segments would all be smaller than one page > > (either normal pages or huge pages) > > When is this the case? With a 4096 byte page, a

Re: [lng-odp] continuous memory allocation for drivers

There is no such module. If it was upstreamable, Intel would have obtained it a long ago On 11 November 2016 at 08:50, Christophe Milard < christophe.mil...@linaro.org> wrote: > I hoped such a kernel module would already exist, but I am surprised > that DPDK would not rely on it. Maybe

Re: [lng-odp] [API-NEXT PATCH 1/3] drv: shm: function to query for physical addresses

On 10 November 2016 at 20:05, Maxim Uvarov wrote: > On 11/10/16 20:21, Christophe Milard wrote: > >> The capability "can_getphy" is introduced and tells whether physical >> address queries are available. >> The function odpdrv_getphy() is added to query for physical

Re: [lng-odp] Classification Queue Group

Good points Brian. I can add some data point with real life observations of a DPI box analyzing two 10Gbps links (four 10 Gbps ports): there are approximately 50M known flows (TCP, UDP...), may be not active (TCP Close_wait). FF On 10 November 2016 at 08:56, Brian Brooks

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

al with L1 initialization (link up/ synchronized...) and L2 initialization (DLCI, MAC (Ethernet, FDDI, TokenRing...)...). Shall we add those L1 and L3 concepts ? FF On 9 November 2016 at 09:38, Francois Ozog <francois.o...@linaro.org> wrote: > > > On 9 November 2016 at

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

On 9 November 2016 at 09:09, Christophe Milard <christophe.mil...@linaro.org > wrote: > > > On 8 November 2016 at 18:19, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Hi Christophe, >> >> We are focusing on network devices which have at

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 framework

Hello, Christophe is working on how we can integrate PCI devices. I wonder if NXP (shreyansh.j...@nxp.com) proposal to DPDK can be leveraged to have a more generic packetio discovery in ODP that couold cover not only PCI but also SoC environments (the proposal can cover DPAA from NXP).

[lng-odp] ODPèDPDK Documentation & build

Building on a vanilla Debian following the README.DPDK has not been totally seamless... As I am not fully sure about my workarounds, it would be nice somebody check and corrects the README.DPDK. Cordially, François-Frédéric *git clone http://92.243.14.124/git/dpdk