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

2017-01-23 Thread Francois Ozog
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

2017-01-20 Thread Francois Ozog
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] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement reference apis

2017-02-20 Thread Francois Ozog
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

2017-02-18 Thread Francois Ozog
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

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

2017-02-13 Thread Francois Ozog
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] measuring time and/or cycles

2017-02-14 Thread Francois Ozog
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

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

2017-02-14 Thread Francois Ozog
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] Why do not odp use a multi-process model?

2017-02-16 Thread Francois Ozog
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] [API-NEXT PATCHv4 2/4] linux-generic: timer: implement odp_timer_capability()

2017-02-17 Thread Francois Ozog
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] 32-bit support in examples

2017-01-20 Thread Francois Ozog
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] Generic handle in ODP

2017-03-02 Thread Francois Ozog
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

2017-03-02 Thread Francois Ozog
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

2017-02-28 Thread Francois Ozog
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] Generic handle in ODP

2017-03-01 Thread Francois Ozog
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] driver interface thinkings....

2016-11-08 Thread Francois Ozog
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

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

2016-11-09 Thread Francois Ozog
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....

2016-11-09 Thread Francois Ozog
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] continuous memory allocation for drivers

2016-11-11 Thread Francois Ozog
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] continuous memory allocation for drivers

2016-11-11 Thread Francois Ozog
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] Classification Queue Group

2016-11-10 Thread Francois Ozog
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] [API-NEXT PATCH 1/3] drv: shm: function to query for physical addresses

2016-11-10 Thread Francois Ozog
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] virtio and vhost support in ODP

2016-11-16 Thread Francois Ozog
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] [API-NEXT PATCHv2 3/5] api: init: driver load function added

2016-11-17 Thread Francois Ozog
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

2016-11-17 Thread Francois Ozog
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

2016-11-17 Thread Francois Ozog
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] enumerator and driver registration

2016-11-21 Thread Francois Ozog
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

2016-11-21 Thread Francois Ozog
> 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

[lng-odp] Driver framework

2016-10-26 Thread Francois Ozog
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

2016-10-11 Thread Francois Ozog
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

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

2016-11-29 Thread Francois Ozog
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

2016-11-29 Thread Francois Ozog
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] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

2016-12-06 Thread Francois Ozog
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

2016-12-06 Thread Francois Ozog
; 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

2016-12-06 Thread Francois Ozog
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

2016-12-07 Thread Francois Ozog
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] Driver registration: object version control

2016-11-29 Thread Francois Ozog
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] Driver registration: object version control

2016-11-29 Thread Francois Ozog
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] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

2016-12-06 Thread Francois Ozog
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] api for small buffer allocations

2017-01-03 Thread Francois Ozog
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] register_notifier

2017-01-05 Thread Francois Ozog
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] register_notifier

2017-01-05 Thread Francois Ozog
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] api for small buffer allocations

2017-01-02 Thread Francois Ozog
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] 32b support in ODP-Cloud

2017-03-23 Thread Francois Ozog
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] 32b support in ODP-Cloud

2017-03-29 Thread Francois Ozog
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] My last day at linaro/LNG

2017-03-31 Thread Francois Ozog
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] DPDK integration under DDF

2017-07-12 Thread Francois Ozog
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

2017-06-15 Thread Francois Ozog
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

2017-06-15 Thread Francois Ozog
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] generic core + HW specific drivers

2017-10-06 Thread Francois Ozog
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

2017-10-04 Thread Francois Ozog
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

2017-10-04 Thread Francois Ozog
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

2017-10-03 Thread Francois Ozog
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

2017-10-03 Thread Francois Ozog
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] generic core + HW specific drivers

2017-10-03 Thread Francois Ozog
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] Modular Pkt I/O - Status

2017-08-29 Thread Francois Ozog
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] odp api to query free/tottal ram

2017-10-24 Thread Francois Ozog
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

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

2017-11-29 Thread Francois Ozog
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

2017-11-09 Thread Francois Ozog
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

2017-11-01 Thread Francois Ozog
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] IPsec and crypto performance and OpenSSL

2017-12-11 Thread Francois Ozog
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

2017-12-11 Thread Francois Ozog
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

2017-12-09 Thread Francois Ozog
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

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

2017-10-30 Thread Francois Ozog
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

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

2017-10-27 Thread Francois Ozog
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

2017-10-27 Thread Francois Ozog
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] Relation between Enumerator class and Enumerator

2017-10-27 Thread Francois Ozog
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 à

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

2017-10-27 Thread Francois Ozog
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] odp api to query free/tottal ram

2017-10-23 Thread Francois Ozog
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] Relation between Enumerator class and Enumerator

2017-10-27 Thread Francois Ozog
(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] DDF discussions taking time

2017-10-27 Thread Francois Ozog
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] DDF discussions taking time

2017-10-27 Thread Francois Ozog
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

2017-10-27 Thread Francois Ozog
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

2017-10-27 Thread Francois Ozog
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

2017-10-27 Thread Francois Ozog
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

2017-10-27 Thread Francois Ozog
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] Flow aware scheduler enhancement for ODP

2018-04-06 Thread Francois Ozog
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] v1.20.0.0 has been released

2018-12-04 Thread Francois Ozog
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

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

2019-01-28 Thread Francois Ozog
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 , , <