Re: [lng-odp] [PATCH] linux-generic: pktio: fix SEGV after odp_pktio_inq_remdef()

On Thu, Apr 2, 2015 at 7:49 PM, Stuart Haslam wrote: > Calling odp_pktio_inq_remdef() causes the pktio's inq_default to be set > to ODP_QUEUE_INVALID, but when the scheduler later polls the pktio it > fails to check the validity of inq_default and ends up passing a bogus > pointer to queue_enq_mul

Re: [lng-odp] [PATCH NETMAP 0/2] Fix pktio related APIs

Applied! /Ciprian On Fri, Mar 27, 2015 at 7:56 PM, Ciprian Barbu wrote: > First patch fixes odp_pktio_mac_addr and second patch fixes odp_pktio_mtu, > odp_pktio_promisc_mode and odp_pktio_promisc_mode_set > > Ciprian Barbu (2): > linux-netmap: implement odp_pktio_mac_addr > linux-netmap: add

[lng-odp] ODP port to a new architecture

Hi all, At Kalray we are designing a manycore processor for packet processing, and we are currently developing our SDK. We really like the ODP approach and we want to implement ODP on our architecture. We know the API and architecture is still a work-in-progress, but we are ok with that and

[lng-odp] [PATCHv10] validation: add new test l2fwd_run

Signed-off-by: Maxim Uvarov --- v10: in odp_l2fwd_run simple add PATH to find generator and l2fwd binary. test/performance/Makefile.am | 2 +- test/performance/odp_l2fwd_run | 65 ++ 2 files changed, 66 insertions(+), 1 deletion(-) create mode 100755

Re: [lng-odp] ODP port to a new architecture

On 04/03/15 11:33, Benoît Ganne wrote: Hi all, At Kalray we are designing a manycore processor for packet processing, and we are currently developing our SDK. We really like the ODP approach and we want to implement ODP on our architecture. We know the API and architecture is still a work-in

Re: [lng-odp] 【Question about the out queue of pktio】

On 04/03/15 06:19, Zhujianhua wrote: Hi, It seems there is no API for setting the default out queue but only getting the default out queue(odp_pkio_outq_getdef) while both are there for default in queue (odp_pkio_inq_setdef/getdef). Then the question is who should create this default out qu

Re: [lng-odp] [PATCH] linux-generic: pool: check for NULL params before dereference

Merged, Maxim. On 04/03/15 00:10, Bill Fischofer wrote: On Thu, Apr 2, 2015 at 6:11 AM, Stuart Haslam mailto:stuart.has...@linaro.org>> wrote: Signed-off-by: Stuart Haslam mailto:stuart.has...@linaro.org>> Reviewed-by: Bill Fischofer > ---

Re: [lng-odp] [PATCH] linux-generic: support running with restricted cpu set

On 04/02/15 18:21, Stuart Haslam wrote: -void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl, +int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl, That is is interesting do we consider helper API change as ODP API change or not. Maxim. __

[lng-odp] [Bug 706] odp: l2fwd-dpdk port unable to spwan coremask specified number of threads

https://bugs.linaro.org/show_bug.cgi?id=706 --- Comment #6 from Santosh Shukla --- odp_l2fwd at times shows segfault. It is inconsistent. Investigating. -- You are receiving this mail because: You are on the CC list for the bug.___ lng-odp mailing lis

Re: [lng-odp] [PATCH 1/3] validation: pktio: fix memory corruption

Merged this patch. Maxim. On 04/02/15 14:07, Stuart Haslam wrote: A magic number, used to ensure jumbo frames are transmitted and received in full, is written to the end of a packet buffer at a fixed offset of 9170 bytes. However for non-jumbo tests this is way beyond the end of the allocated b

Re: [lng-odp] [PATCH 2/3] validation: pktio: support arbitrary length packets

Merged this patch. Maxim. On 04/02/15 14:07, Stuart Haslam wrote: Rework the way test packets are generated in order to allow generating and verifying arbitrary length packets. Signed-off-by: Stuart Haslam --- test/validation/odp_pktio.c | 140 ++--

Re: [lng-odp] [API-NEXT PATCHv3] api: packet: relax return code to use non-zero for true

Merged to api-next. Maxim. On 03/26/15 19:07, Bill Fischofer wrote: This change addresses Bug https://bugs.linaro.org/show_bug.cgi?id=1334 Signed-off-by: Bill Fischofer --- Note that for v3 this patch is split. The test change doe not affect the ODP API and hence can be merged as part of the

[lng-odp] [Bug 1334] packet flag APIs are booleans and should follow boolean guidelines

https://bugs.linaro.org/show_bug.cgi?id=1334 Maxim Uvarov changed: What|Removed |Added Resolution|--- |FIXED CC|

Re: [lng-odp] ODP port to a new architecture

Hi Maxim, thanks for your quick answer! Glad to see new people interesting ODP. There are many ways to participate: mailing list, regular public meeting on Tuesday or be a member of Linaro LNG team with it's benefits (drive next API development, use LNG infrastructure, set and prioritize tasks).

Re: [lng-odp] ODP port to a new architecture

Hi Benoît, What you describe seems quite doable with the current ODP API set, however, we're always looking to better refine them to best match the capabilities of the various platforms that support ODP--especially those that embody novel HW architectures--so I'd encourage you to participate in th

Re: [lng-odp] NO ODP API for Packet classification and Packet Shaping

On 03/30/2015 03:34 PM, Zhujianhua wrote: @ Jerin Jacob: What will happen if odp_cos_set_pool(odp_cos_t cos_id, odp_buffer_pool_t pool_id) was called twice? Will the new pool_id replace the old one or the CoS have two pools? @Taras: Assume: set several pools per pktio interface. What will happe

Re: [lng-odp] NO ODP API for Packet classification and Packet Shaping

On 3 April 2015 at 22:00, Taras Kondratiuk wrote: > On 03/30/2015 03:34 PM, Zhujianhua wrote: >> >> @ Jerin Jacob: >> What will happen if odp_cos_set_pool(odp_cos_t cos_id, odp_buffer_pool_t >> pool_id) was called twice? >> Will the new pool_id replace the old one or the CoS have two pools? >> >>

Re: [lng-odp] ODP port to a new architecture

Hi Bill, Thanks for the feedback. It was more or less what I was thinking about, but the fact that pktio_open() took a pool in parameter made me think it was per-iface. Thanks, Ben. Sent from Samsung Mobile. Original message From: Bill Fischofer Date:03/04/2015 18:14 (GMT

Re: [lng-odp] ODP port to a new architecture

The pool specified on odp_pktio_open() is simply the default pool to use if a PMR doesn't provide a more specific match to a CoS. In the latter case the pool associated with the CoS applies. On Fri, Apr 3, 2015 at 12:32 PM, Benoît Ganne wrote: > Hi Bill, > > Thanks for the feedback. It was more

Re: [lng-odp] NO ODP API for Packet classification and Packet Shaping

As currently defined, there is a many-to-one mapping between CoS and pools, but a single CoS can only be associated with a single pool. PMRs are used to determine which CoS an incoming packet will be assigned to, and hence to the pool it will reside in. It is an application responsibility to ensu