document/d/1KjcdpidVqMCDa6FXURSxrTwFjkmb1_pKz54m7eYvVMo/edit
──
Bill Fischofer is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/399698371
One tap mobile
+17207072699,,399698371# US
+16465588656,,399698371# US (New York)
Dial by your location
+1 72
Hi Daniel. Thanks for your question.
The spec for the odp_hash_crc32() API looks like this:
/**
* Calculate CRC-32
*
* Calculates CRC-32 over the data. The polynomial is 0x04c11db7.
*
* @param data Pointer to data
* @param data_len Data length in bytes
* @param init_val CRC generator initializati
This event has been canceled.
Title: OpenDataPlane (ODP) Public Call
Meeting notes document:
https://docs.google.com/a/linaro.org/document/d/1KjcdpidVqMCDa6FXURSxrTwFjkmb1_pKz54m7eYvVMo/edit
──
Bill Fischofer is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https
This event has been canceled.
Title: OpenDataPlane (ODP) Public Call
Meeting notes document:
https://docs.google.com/a/linaro.org/document/d/1KjcdpidVqMCDa6FXURSxrTwFjkmb1_pKz54m7eYvVMo/edit
──
Bill Fischofer is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https
esday from Tue Dec 4 to Tue Dec 18
Central Time - Chicago (changed)
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* lng-odp@lists.linaro.org
* ilias.ap
This event has been changed.
Title: OpenDataPlane (ODP) Public Call
Meeting notes document:
https://docs.google.com/a/linaro.org/document/d/1KjcdpidVqMCDa6FXURSxrTwFjkmb1_pKz54m7eYvVMo/edit
──
Bill Fischofer is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https
I'd like to hear from Janne as to what OFP would prefer. I'll also add this
to the discussion agenda for tomorrow's public call. Thanks.
On Mon, Dec 10, 2018 at 2:28 PM Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> On 10/12/2018 22:11, Bill Fisch
I assume that's an API change? Can you put together a draft PR of what what
would look like that we can discuss?
On Mon, Dec 10, 2018 at 1:00 PM Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> Hello,
>
> I have been reworking compression API implementation to properly
> allo
e for details.
When: Tue Dec 4, 2018 9am – 10am Central Time - Chicago
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* Mike Holmes
* Dmitry Eremin-
both iOS
and Android. See the meeting landing page for details.
When: Tue Nov 20, 2018 9am – 10am Central Time - Chicago
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fisc
u'd
like to see, feel free to create a PR to add it if that would better
illustrate it.
>
>
> Liron
>
>
>
> *From:* Bill Fischofer
> *Sent:* Monday, October 22, 2018 22:40
> *To:* Liron Himi
> *Cc:* Elo, Matias (Nokia - FI/Espoo) ;
> lng-odp-forward
>
er platforms.
If you'd like to discuss specifics we can do that during the weekly ODP
public call (15:00 UTC every Tuesday). Feel free to join us for tomorrow's
call or whenever else is convenient.
>
>
> Liron
>
>
>
> *From:* Bill Fischofer
> *Sent:* Monday, Oct
approach is what DPDK offer with its EAL infrastructure.
>
>
>
> Thanks,
>
> Liron
>
>
>
> *From:* Bill Fischofer
> *Sent:* Monday, October 22, 2018 17:47
> *To:* Elo, Matias (Nokia - FI/Espoo)
> *Cc:* Liron Himi ; lng-odp-forward <
> l
Hi Liron,
Sorry for the delay in responding as I was vacationing last week. As Matias
noted, ODP does not have APIs for dealing with physical addresses, since
the concept of a physical address tends to be very platform-specific and
not universally shared. ODP refers to packet objects symbolically
11am Central Time - Chicago
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* song@linaro.org
* sreejith.surendrann...@linaro.org
* ola.liljed...@ar
Yes, these APIs are available however only platforms with HW support will
show a practical difference in behavior. These APIs are hints to the
implementation, which is why you cannot assume you hold the lock until
after odp_schedule_order_lock_wait() completes.
On Tue, Sep 4, 2018 at 6:41 AM Yan,
While ODP itself is platform-neutral and architecture independent, which
platforms to test on is a question of resourcing. So this is really an
SC-level question. We'll support whatever architectures the ODP membership
wishes to emphasize, but the current test focus remains Arm and x86.
If we have
Bala had talked about a simplified TM API a while back. Perhaps it's timely
to reopen that discussion?
On Tue, Aug 7, 2018 at 2:47 PM Maxim Uvarov wrote:
> I'm looking on errors of our example for traffic manager. There is
> missing destroy path for created tm queues. Now when I look to it I'm
>
On Wed, Jun 27, 2018 at 2:03 PM Maxim Uvarov
wrote:
> On 27.06.2018 19:41, Bill Fischofer wrote:
> > Is this an ODP question or a DPDK question? Is this unique to Ubuntu
> > 14.04? I notice that release goes out of support in April 2019 so I'm
> > wondering if it'
Is this an ODP question or a DPDK question? Is this unique to Ubuntu
14.04? I notice that release goes out of support in April 2019 so I'm
wondering if it's still an important release to carry.
On Wed, Jun 27, 2018 at 10:41 AM Maxim Uvarov
wrote:
> Ubuntu 14.04.5 which I run in container uses g
o send the packet set like:
>>
>> pkt1 =
>> Ether(dst='08:00:27:4C:55:CC',src='08:00:27:76:B5:E0')/IP(ds
>> t='192.168.111.1',src='192.168.111.2')
>>
>> And sending it through veth1. Am I doing something wrong? Do you have
Hi Daniel. Can you give a bit more detail?
- What version of ODP are you using? Is this the odp-linux or odp-dpdk
reference implementations from GitHub or some other implementation?
- The platform / system you're running on. x86? Arm? Something else?
- A small code snippet / test program illustrat
Glad to hear, Daniel. Please consider subscribing to this e-mail list as
that will ensure faster response as otherwise I have to manually approve
each of your posts. Just go to
https://lists.linaro.org/mailman/listinfo/lng-odp for subscription
instructions.
Thanks.
On Tue, Jun 5, 2018 at 11:35 AM
As discussed during this week's ODP public call, due to a scheduling
conflict with a Linaro internal meeting, the call for Tuesday May 29th is
cancelled. The regular weekly ODP public call will resume on Tuesday June
5th at the usual time (15:00 UTC).
See you there.
Thank you.
Bill Fischofer
11am Central Time
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* Maxim Uvarov
* Bala Manoharan
* mykyta.iziumt...@linaro.org
* Mike Holmes
* Alex
Thanks, Bala. The link seems to have been corrupted in your post. The
proper link is here:
https://docs.google.com/document/d/1HDHHxSMtHNWl9_sWIVoKRaB4zdsb4hT-PKK6sUB708s/
On Thu, May 17, 2018 at 7:27 AM, Bala Manoharan
wrote:
> Hi All,
>
> Below is the initial design draft for Flow aware schedu
Brian, can you comment on this? David did you want to submit a PR for this?
On Wed, May 16, 2018 at 6:26 AM, David Nystrom
wrote:
> Hi,
>
> All schedulers except the scalable scheduler seem to respect scheduled
> timer queues, except the scalable scheduler.
> Is this by design or mistake ?
>
> T
On Sat, Apr 28, 2018 at 9:20 AM, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> Hi,
>
> On 28 April 2018 at 16:44, Bill Fischofer
> wrote:
> > If we're going to be doing formal distributions each of these should have
> > their own branc
If we're going to be doing formal distributions each of these should have
their own branch which are created off of the main base release branch. So
TigerMoth_LTS is the "master" branch and it can have sub-branches for
various distributions created from it. This permits distributions to
control whi
On Fri, Apr 6, 2018 at 12:12 PM, Francois Ozog
wrote:
>
>
> On 6 April 2018 at 19:02, Bill Fischofer
> wrote:
>
>>
>>
>> On Fri, Apr 6, 2018 at 11:37 AM, Francois Ozog
>> wrote:
>>
>>> In the case of DPI, I came across this.
>>&g
Thanks, Bala. I like this direction. One point to discuss is the idea
of flow hashes vs. flow ids or labels. A hash is an
implementation-defined value that is derived from some
application-specified set of fields (e.g., based on tuples). A flow id
or label is an application-chosen value that is use
return -ENOMEM;
}
}
The reported -12 error code is -ENOMEM so I'd say the issue is some
sort of memory allocation failure.
On Wed, Mar 28, 2018 at 8:43 AM, gyanesh patra wrote:
> Hi Bill,
> I tried with Matias' suggestions but without success.
>
> P G
Hi Gyanesh,
Have you had a chance to look at
https://bugs.linaro.org/show_bug.cgi?id=3657 and see if Matias' suggestions
are helpful to you?
Thanks,
Regards,
Bill
11am Central Time
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* ilias.apalodi...@linaro.org
* qing.cha...@huawei.com
* sreejith.surendrann...@linar
Thanks. I've opened Bug https://bugs.linaro.org/show_bug.cgi?id=3657
to track this.
On Tue, Mar 6, 2018 at 1:36 PM, gyanesh patra wrote:
> Hi,
> I am coming back with the same issue here. As the odp-dpdk is updated to
> the recent DPDK version inline with the ODP code base, now both ODP repo
> an
On Mon, Feb 19, 2018 at 7:36 AM, Bogdan Pricope
wrote:
>
> On 17 February 2018 at 03:36, Bill Fischofer
> wrote:
> > Changed to post this to the ODP mailing list, as this is a good topic to
> > discuss there.
> >
> > Let's first back up a bit and discu
Changed to post this to the ODP mailing list, as this is a good topic to
discuss there.
Let's first back up a bit and discuss the intent behind packet references.
Packets typically consist of one or more headers followed by a payload.
References are designed to allow multiple unique headers to sha
oo) wrote:
> >
> >
> >> -Original Message-
> >> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org
> ]
> >> Sent: Thursday, February 15, 2018 4:00 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo) ;
> >> Bill Fischofer
> >>
We already have such a routine: odp_packet_offset(pkt, 0, &seg_len, NULL);
The fourth parameter of this routine returns the odp_packet_seg_t of the
segment containing the specified offset (2nd parameter). I'm not aware of
any use of this capability and would be happy to see it deprecated. We have
to handle them as e-mail discussions or as
topics for next week's call.
Thank you.
Bill Fischofer
Linaro
; > tx: pktio 1, queue 2
> > > > > worker 5
> > > > > rx: pktio 1, queue 2
> > > > > tx: pktio 0, queue 2
> > > > > worker 6
> > > > > rx: pktio 0, queue 3
> > > > > tx: pktio 1, queue
Thanks, Gyanesh, that does sound like a bug. +cc Matias: Can you comment on
this?
On Mon, Feb 5, 2018 at 5:09 AM, gyanesh patra
wrote:
> I am testing an l2fwd use-case. I am executing the use-case with two
> CPUs & two interfaces.
> One interface with 2 Rx queues receives pkts using 2 thre
Thanks Tom. Please subscribe to the ODP mailing list at
https://lists.linaro.org/mailman/listinfo/lng-odp to be able to post.
Otherwise I have to manually approve each post, which will cause delay.
To contribute you (or your company) needs to have an individual or
corporate contribution agreement
Looks like all pending PRs written against api-next should be rebased.
On Mon, Jan 15, 2018 at 3:00 PM, Maxim Uvarov
wrote:
>
> git push -f to api-next branch. Because of code is similar to master
> there is no need to have branch with not plain history (merge from
> master to api-next and back)
Thanks. I didn't realize those were scrollable frames. I now see that they
are.
On Sat, Jan 13, 2018 at 1:46 AM, Maxim Uvarov
wrote:
> On 01/12/18 20:27, Bill Fischofer wrote:
> > Looks like something changed in the GitHub scripts. The link to the
> Travis
> > run f
Looks like something changed in the GitHub scripts. The link to the Travis
run from the PR is no longer present. This is not good.
Per-CoS hashing is a newer feature that's part of ODP Tiger Moth. It was
introduced in v1.16.0.0 I believe. We're now on v1.17.0.0
On Thu, Jan 4, 2018 at 10:22 AM, Oriol Arcas
wrote:
> Hi Bala,
>
> I didn't find any hashing parameter in the CoS API, is it implemented or a
> suggestion?
>
> --
>
ODP has several mechanisms for controlling workload distribution. The hash
functions can distribute packets from a given PktIO to a group of queues,
however the classifier is the most flexible means of controlling this. A
CoS defines a target queue for the flow. This is the queue that receives
inpu
Thanks, Maxim. Happy New Year. 2018 should be an exciting one for ODP.
On Mon, Jan 1, 2018 at 2:46 PM, Maxim Uvarov
wrote:
> Hello team,
>
>
> I put 2 tags to repo it's v1.17.0.0 and v1.17.0.0_tigermoth_rc1.
>
> ODP API changes are really big can be found in CHANGELOG for
> corresponding tag or
Thanks Dmitry. This is a good and timely topic, given both the Tiger Moth
RC series now starting as well as the Caterpillar development work that
we're going to start absorbing.
I suspect Proposal 2 is the more flexible one, but we need to define the
scope of these "topics" better than we've done
: Tue Jan 2, 2018 9am – 10am Central Time
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* sachin.sax...@linaro.org
* Petri Savolainen
* huang
: Tue Dec 26, 2017 9am – 10am Central Time
Where: http:://bluejeans.com/564564564564564, BlueJeans Video Conference -
http://bluejeans.com/564564564564
Calendar: lng-odp@lists.linaro.org
Who:
* Bill Fischofer - creator
* ola.liljed...@arm.com
* Mike Holmes
* Alexandru Badi
Since IPv6 doesn't have an L3 checksum and since we don't have a "not
applicable" enum, I'd say OK would be the best choice.
On Mon, Dec 18, 2017 at 11:25 PM, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> Hello,
>
> I was working on checksum parsing/status. What is the L3
I think we've pretty much abandoned the notion that linux-generic will
support threads as separate processes as there seems to be little
justification for it. The current plan is to continue this assumption in
the "2.0" code base as well. So having OpenSSL rely on threads sharing the
same address s
it may be said that this function can return NULL on some
> platforms. It will just prevent some applications to run on those
> platforms. Which is also a design choice that would push the upper layers
> to add the information (odp_packet_t in our case) in their meta data
> (blib_
On Fri, Dec 8, 2017 at 2:49 PM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:
> On 8 December 2017 at 13:40, Bill Fischofer
> wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 1:06 PM, Honnappa Nagarahalli
> > wrote:
> >>
> >> O
On Fri, Dec 8, 2017 at 1:06 PM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:
> On 7 December 2017 at 22:36, Bill Fischofer
> wrote:
> >
> >
> > On Thu, Dec 7, 2017 at 10:12 PM, Honnappa Nagarahalli
> > wrote:
> >>
> >> O
ntation) method to get
> the ODP handle which is required for every application using ODP.
> What applications other than VPP are using the ODP now? How do they solve
> this issue?
>
> On 8 December 2017 at 05:36, Bill Fischofer
> wrote:
>
>>
>>
>> On Thu, D
On Thu, Dec 7, 2017 at 10:12 PM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:
> On 7 December 2017 at 17:36, Bill Fischofer
> wrote:
> >
> >
> > On Thu, Dec 7, 2017 at 3:17 PM, Honnappa Nagarahalli
> > wrote:
> >>
> >> T
al storage in VLIB.
>
> Michal, can you send a PR to ODP for the API so that we can debate the
> feasibility of the API for Cavium/NXP platforms.
>
That's the point. An API that is tailored to a specific implementation or
application is not what ODP is about.
>
> On 7 Decemb
all.
So my advice would be to stash the handle in the VLIB buffer for now and
focus on exploiting the native IPsec acceleration capabilities that ODP
will permit.
> On 7 December 2017 at 19:02, Bill Fischofer
> wrote:
>
>> Ping to others on the mailing list for opinions on t
On Thu, Dec 7, 2017 at 12:55 PM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:
> On 7 December 2017 at 08:01, Bogdan Pricope
> wrote:
> > TX is at line rate. Probably will get RX at line rate in direct mode,
> too.
> > Problem is how can you see the performance increase/degradati
ins only offsets). Reading pointer for each packet from
> VLIB would require to fetch 10 million cachelines per second.
> Using prefetches does not help.
>
> On 7 December 2017 at 18:37, Bill Fischofer
> wrote:
>
>> Yes, but _odp_packet_inline.udate is clearly not in the VLIB
r only 10Mpps and with this new api 10.6Mpps.
>
> On 7 December 2017 at 18:04, Bill Fischofer
> wrote:
>
>> How would calling an API be better than referencing the stored data
>> yourself? A cache line reference is a cache line reference, and presumably
>> the VLIB
Of interest to the ODP community.
-- Forwarded message --
From: P4.org
Date: Thu, Dec 7, 2017 at 10:45 AM
Subject: [P4-announce] [Blog Post] P4 Runtime - Putting the Control Plane
in Charge of the Forwarding Plane.
To: p4-annou...@lists.p4.org, p4-...@lists.p4.org, p4-des...@lists
How would calling an API be better than referencing the stored data
yourself? A cache line reference is a cache line reference, and presumably
the VLIB buffer is already in L1 since it's your active data.
On Thu, Dec 7, 2017 at 10:45 AM, Michal Mazur
wrote:
> Hi,
>
> For odp4vpp plugin we need a
ODP currently does not have any APIs for PFC processing. We've discussed
this in the past but there have been no use cases brought forward for it.
Due to the timings involved PFC requires HW support, so I assume DPDK is
taking advantage of NIC configuration options here.
On Wed, Dec 6, 2017 at 2:3
On Tue, Nov 28, 2017 at 9:28 AM, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> Hello,
>
> On 20/11/17 18:23, Bill Fischofer wrote:
> > Traffic Flow Confidentiality (TFC) is a feature of SAs according to RFC
> > 4303 that must be negotiated on
As a way of easing the sync burden on the 2.0 development branch, what do
folks think of the idea of asking that new PRs being posted to api-next
also be posted to 2.0? The contributions to api-next should be winding down
as we approach Tiger Moth freeze, so this will help keep things in sync as
we
Traffic Flow Confidentiality (TFC) is a feature of SAs according to RFC
4303 that must be negotiated on a per-SA basis before it is used. So This
would need to be hooked into higher-level protocols.
>From an ODP perspective, it would be an additional set of parameters on the
odp_ipsec_sa_create()
On Mon, Nov 13, 2017 at 9:26 AM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:
> On 10 November 2017 at 05:35, Dmitry Eremin-Solenikov
> wrote:
> > Hello,
> >
> > Historically ODP helper provided protocol-related headers with
> > linux-generic ODP implementation using modified pr
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 Mykyta have gotten packet I/O through net_mdev.
I'll let them characterize whether it's "flying"
On Fri, Oct 27, 2017 at 4:54 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
>> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahall
On Fri, Oct 27, 2017 at 3:43 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 20:35, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> a écrit :
>
>> On 27 October 2017 at 13:35, Bill Fischofer
>> wrote:
>>
>>>
>>>
>>> O
On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
> a écrit :
>
>> The problem with scanning, especially in a VNF environment, is that (a)
>> the application probably isn't authorized to to that
>>
&g
wrote:
>
>
> On 27 October 2017 at 09:50, Bill Fischofer
> wrote:
>
>> ODP 2.0 assumes Linux system services are available so the question of
>> how to operate in bare metal environments is a separate one and up to those
>> ODP implementations. Again the applicati
nel based fast packet
> IO So there will be topics where I'll push hard to explain (not impose)
> why we should go a harder route. This slows things down but I think this is
> worth it.
>
> FF
>
> Le ven. 27 oct. 2017 à 06:23, Honnappa Nagarahalli <
> honnappa.nagarah
I think you've captured the distinction correctly. The larger question is
what does ODP itself need to do with this? When an interface name is
presented to odp_pktio_open() it is the application's responsibility to
provide a name string that can be mapped to the device that should be
opened. ODP us
I agree with Maxim. Best to get one or two working drivers and see what
else is needed. The intent here is not for ODP to become another OS, so I'm
not sure why we need to concern ourselves with bus walking and similar
arcana. Linux has already long solved this problem. We should leverage
what's th
Hi Liron,
Can you try this against the master or api-next branches of odp.git? I know
we are currently doing cross-compile testing for aarch64 in Travis and
aren't seeing this problem. If that's the case then this problem should
resolve itself in the next tagged release, which should be out within
There are no immediate plans for this feature. As an open source project,
ODP moves in the direction of its contributors. If this is of importance to
you, please consider submitting patches to add it.
On Wed, Oct 25, 2017 at 11:54 AM, Liron Himi wrote:
> Hi,
>
> Is there any intention to add sup
I'm all for using topic branches, especially since we've switched to GitHub
and most contributors are now familiar with it and using pull requests
rather than raw patches sent to the mailing list. The whole reason for
api-next was to separate in-progress API changes from regular maintenance
patches
On Tue, Oct 24, 2017 at 3:00 PM, Github ODP bot wrote:
> From: Dmitry Eremin-Solenikov
>
> According to the discussion on mailing list, most of implementations
> will not be able to support odp_ipsec_sa_disable() status event
> directly. Instead they will submit a dummy packet to that SA. Then
On Tue, Oct 24, 2017 at 7:49 AM, Peltonen, Janne (Nokia - FI/Espoo) <
janne.pelto...@nokia.com> wrote:
> Hi,
>
> Comments below:
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> > Sent: Tuesday, October 24, 2017 2:00 PM
>
On Tue, Oct 24, 2017 at 3:39 AM, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:
> Hello,
>
> On 23 October 2017 at 20:56, Bill Fischofer
> wrote:
> > 2. All other IPsec events are reported as events of type
> ODP_EVENT_PACKET,
> > su
is contrary to this goal. Hence the number of "in
flight" packets (plus a safety margin) is what determines the needed pool
size, and that's more a function of the number of pktios and their I/O
rates than the available RAM.
>
> Maxim.
>
>
> In general we need allocated
>
calling
> odp_ipsec_sa_disable() and then sometime later getting some event /or/
> dummy packet (I don't care which) back that the SA can be safely destroyed
> would work just fine for us. Any hardware specifics could be hidden from
> the application in the HW-specific part of th
Applications should request the amount of storage they need (possibly as
configured) rather than trying to grab everything they can find "just in
case". Especially in an NFV environment that's not very neighborly behavior.
On Mon, Oct 23, 2017 at 2:44 AM, Dmitry Eremin-Solenikov <
dmitry.ereminsol
.config.pktin.all_bits) {
> ODP_ERR("Unsupported input configuration option\n");
> return -1;
> }
> if (config->pktout.all_bits & ~capa.config.pktout.all_bits) {
> ODP_ERR("Unsupported output configuration option\n");
> return -1;
> }
> .
&
On Thu, Oct 19, 2017 at 8:00 AM, Bogdan Pricope
wrote:
> Hi Petri and Janne,
>
> On APIs:
>
> void odp_packet_l3_chksum_insert(odp_packet_t pkt, int l3);
> void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4);
>
> What is the expected behavior is checksum is requested but interface
> does n
.fr/b2c/insidesecure/signatureMail/inside-logo-signature.jpg]
>
> *Pascal van Leeuwen*
> Senior IC Design Engineer
>
> Tel. : +31 (0)73 65 81 900
>
>
> www.insidesecure.com
>
>
>
>
>
> CONFIDENTIALITY - This e-mail and any attachments hereto are intended only
> fo
t the named recipient, please notify the sender
> immediately and do not disclose the contents to any person, use it for any
> purpose, or store or copy the information on any medium. Please permanently
> delete the original copy of this e-mail and/or any attachments thereto and
> any
We discussed this during the ODP public call today and had the benefit of
Pascal Van Leeuwen's participation. Pascal is a HW guy and explained some
of the issues that HW IPsec support faces.
HW recognizes an active SA by it being in a HW lookup table. From an ODP
implementation perspective, odp_ip
On Tue, Oct 17, 2017 at 2:14 AM, Savolainen, Petri (Nokia - FI/Espoo)
wrote:
>
>
> From: Bill Fischofer [mailto:notificati...@github.com]
> Sent: Tuesday, October 17, 2017 2:20 AM
> To: Linaro/odp
> Cc: Savolainen, Petri (Nokia - FI/Espoo) ; Author
>
> Subject: Re: [Lin
On Tue, Oct 17, 2017 at 3:04 AM, Savolainen, Petri (Nokia - FI/Espoo)
wrote:
>> typedef struct odp_pool_param_t {
>> /** Pool type */
>> @@ -192,17 +193,34 @@ typedef struct odp_pool_param_t {
>>
>> /** Parameters for packet pools */
>> struct {
>> -
On Mon, Oct 16, 2017 at 7:59 AM, Github ODP bot wrote:
> From: Petri Savolainen
>
> Added packet pool parameter 'max_num', so that 'num' parameter
> can be round up by the implementation. Most implementations have
> a fixed segment size, and need this flexibility. For example,
> when 'len' is lar
On Mon, Oct 16, 2017 at 8:00 AM, Github ODP bot wrote:
> From: Petri Savolainen
>
> Remove anonymous union from pool parameter structure.
> Union makes it impossible to initialize parameters per
> pool type (use other values than all zeros). This change
> is not visible to applications (union was
On Mon, Oct 16, 2017 at 7:59 AM, Github ODP bot wrote:
> From: Petri Savolainen
>
> Additional packet length and number specification gives
> more information to implementation about intended packet
> length distribution in the pool. This enables e.g. correct
> initialization when pool implementa
I've looked over the code and the biggest issue surrounds the use of
#ifdefs in open code. The issue is that the scheduler behaves
significantly different based on whether it's running on AArch64 vs.
other architectures. This means that code coverage is dependent on the
target platform.
>From a mo
1 - 100 of 4369 matches
Mail list logo
