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:
On 23 January 2017 at 10:49, Joe Savage
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.
Le ven. 20 janv. 2017 à 13:59, Joe Savage a écrit :
> > Unfortunately, ODP atomics API does not support 128 bit atomics - at
> race conditions are found.
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Fischofer
> > Sent: Saturday, February 18, 2017 6:28 PM
> > To: Francois Ozog <francoi
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
> I've posted patch http://patches.opendataplane.org/patch/8155/ to
> address this issue. It goes on api-next on top of
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
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.
On 14 February 2017 at 19:37, Brian Brooks
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>
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
So I would encourage you to use the version that is compatible with your
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
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
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
> 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>; firstname.lastname@example.org
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
> Sent: 01 March 2017 14:38
> To: Verma, Shally <shally.ve...@cavium.com>; Francois Ozog <
> Cc: email@example.com
> Subject: RE: [lng-odp] Generic handle in ODP
> > -Original Message---
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
with L1 initialization (link up/ synchronized...) and L2 initialization
(DLCI, MAC (Ethernet, FDDI, TokenRing...)...).
Shall we add those L1 and L3 concepts ?
On 9 November 2016 at 09:38, Francois Ozog <francois.o...@linaro.org> wrote:
> On 9 November 2016 at
On 9 November 2016 at 09:09, Christophe Milard <christophe.mil...@linaro.org
> On 8 November 2016 at 18:19, Francois Ozog <francois.o...@linaro.org>
>> Hi Christophe,
>> We are focusing on network devices which have at
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 <
> I hoped such a kernel module would already exist, but I am surprised
> that DPDK would not rely on it. Maybe
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
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).
On 10 November 2016 at 08:56, Brian Brooks
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
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
> 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...
> On 16 November 20
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??
> On 16 November 2016 at 11:45, Francois Ozog <francois.o...@linaro.org>
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
I made a google doc version of this to simplify comments and resolving.
(I gave edit rights to Christophe, Forest and Yi: you should you PrettyCode
addon for syntax
> 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; firstname.lastname@example.org
> > Subject: Re: [lng-odp] virtio and vhost
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).
Building on a vanilla Debian following the README.DPDK has not been totally
As I am not fully sure about my workarounds, it would be nice somebody
check and corrects the README.DPDK.
*git clone http://22.214.171.124/git/dpdk
additional API related to device management and not "packetio" related:
On 29 November 2016 at 20:35, Christophe Milard <
> On 29 November 2016 at 20:00, Francois Ozog <franc
On 29 November 2016 at 19:03, Christophe Milard <
> On 29 November 2016 at 18:13, Francois Ozog <francois.o...@linaro.org>
>> On 29 November 2016 at 16:44, Christophe Milard <
For the link, I think it ate the following it.
Here it is without decoration:
On 6 December 2016 at 16:05, Francois Ozog <francois.o...@linaro.org> wrote:
; On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.o...@linaro.org>
>> Hi Bill,
>> could you clarify if this "device" is related to devicetree as defined by
>> Linaro (https://github.com/devicetree-org/devicetree-specification)
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>
>> Devicetree has been formed by a
> 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.
> *From:* Francois Ozog [mailto:francois
On 29 November 2016 at 10:58, Christophe Milard <
> 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
On 29 November 2016 at 16:44, Christophe Milard <
> On 29 November 2016 at 13:22, Francois Ozog <francois.o...@linaro.org>
>> comments inline
>> On 29 November 2016 at 1
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
On 6 December 2016 at 04:43, Bill Fischofer
all tomorrow, Francois? Maybe a topic to take
> 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
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
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
> On 5 January 2017 at 11:43, Francois Ozog <francois.o...@linaro.org>
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
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
> >> >> 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
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).
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
- ODP and ODP applications should accommodate how HW uses memory on the
receive side, not the oppsoite
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?
On 15 June 2017 at 17:58, Bala Manoharan <bala.manoha...@linaro.org> wrote:
> On 15 June 2017 at 20:00, 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?
On 15 June 2017 at 15:42, Bala Manoharan wrote:
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
there are two mechanisms:
- modular framework
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.
On 4 October 2017 at 14:35, Ilias Apalodimas
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.
On 4 October 2017 at 15:27, Bogdan Pricope
I would leave it tu SoC vendors that can define a reliable and sustainable
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>
> > Hi Maxim
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
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
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
October 2017 at 22:01, Bill Fischofer <bill.fischo...@linaro.org>
> On Mon, Oct 23, 2017 at 2:22 PM, Maxim Uvarov <maxim.uva...@linaro.org>
> > On 10/23/17 18:23, Francois Ozog wrote:
> > > Hi Maxim,
> > >
> > > Is this regula
You may be interested to register for a webinar 9-10am tomorrow Thursday PT.
Bob Monkman and Bill Fischofer will give a presentation on
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).
On 9 November 2017 at 14:18, Maxim Uvarov
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.
On 28 October 2017 at 00:01, Bill Fischofer <bill.fischo...@linaro.org>
> On Fri, Oct 27, 2017 at
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) <
> When playing with IPsec I noticed that the Linux generic
> ODP implementation creates a
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>
>> I'd like to have
I'd like to have SoC vendors feedback on the discussion and on the
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
Le lun. 30 oct. 2017 à 22:23, Bill Fischofer a
> 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
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.
-- Forwarded message --
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.
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
Le ven. 27 oct. 2017 à
In the case of netmdev the device is still there. Please check with Ilias
for detailed behavior of this technology
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
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
(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
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
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>
>> Well, we do not need to scan all the platform because the pktio_open
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>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <francois.o...@li
Le ven. 27 oct. 2017 à 23:51, Bill Fischofer <bill.fischo...@linaro.org> a
> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog <francois.o...@linaro.org>
>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
Le ven. 27 oct. 2017 à 20:35, Bill Fischofer <bill.fischo...@linaro.org> a
> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <francois.o...@linaro.org>
>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer <bill.fischo...@linaro.org>
Le ven. 27 oct. 2017 à 23:54, Francois Ozog <francois.o...@linaro.org> a
> 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>
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
- an option that would calculate
On Tue, 4 Dec 2018 at 16:54, Maxim Uvarov wrote:
> v126.96.36.199 has been released and api-next branch is rebased on top of it.
> == OpenDataPlane (188.8.131.52)
> === Summary of Changes
> ODP v184.108.40.206 is a refresh of ODP, incorporating significant
THis is certainly relevant to ODP...
-- 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 , , <
Mail list logo