Hi,
I have a platform that doesn't support hashing on input queues, only
classification.
I think it be good to add the below to the PKTIO capabilities.
As currently in the capabilities I declare to have several input queues but
application has not idea it cannot activate hash on those queues.
her of the odp_ishm_internal.h files.
Liron
From: Bill Fischofer
Sent: Monday, October 22, 2018 22:40
To: Liron Himi
Cc: Elo, Matias (Nokia - FI/Espoo) ; lng-odp-forward
Subject: Re: [EXT] Re: [lng-odp] Get Physical address
On Mon, Oct 22, 2018 at 1:40 PM Liron Himi
mailto:lir...@marvell.com&g
Hi,
It is for implementing ODP itself on our platform. So yes, we need internal
APIs to get physical address.
Do you have plans to add such internal APIs?
Liron
From: Bill Fischofer
Sent: Monday, October 22, 2018 21:32
To: Liron Himi
Cc: Elo, Matias (Nokia - FI/Espoo) ; lng-odp-forward
, Matias (Nokia - FI/Espoo)
Cc: Liron Himi ; lng-odp-forward
Subject: [EXT] Re: [lng-odp] Get Physical address
External Email
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
Hi,
Is there an external or internal API to retrieve the physical address of a
packet.
I would like to use the linux-generic memory management implementation with
hugepages.
In DPDK there is :
/**
* A macro that returns the IO address that points to the start of the
* data in the mbuf
*
*/
#defi
Hi,
I'm trying to understand when pktio implementation should set the L4 offset.
In point of view, if there is a known L3 header than the L4 offset should be
set to the L3-offset + L3 header length.
I noticed that Linux generic implementation is not as above. E.g. if there is
only IP header and
This is great.
On which version it will be released? 1.16? or later?
Liron
-Original Message-
From: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolai...@nokia.com]
Sent: Friday, November 10, 2017 13:19
To: Liron Himi ; Bala Manoharan
Cc: lng-odp@lists.linaro.org
Subject: RE
Hi Petri,
See comments inline
Liron
-Original Message-
From: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolai...@nokia.com]
Sent: Friday, November 10, 2017 13:13
To: Liron Himi ; Bala Manoharan
Cc: lng-odp@lists.linaro.org
Subject: RE: [EXT] Re: [lng-odp] classifier with
Hi,
See comments inline
Liron
-Original Message-
From: Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Friday, November 10, 2017 13:07
To: Liron Himi
Cc: Savolainen, Petri (Nokia - FI/Espoo) ;
lng-odp@lists.linaro.org
Subject: Re: [EXT] Re: [lng-odp] classifier with pktio in
as a
result the packet will be return to originated queue.
Liron
-Original Message-
From: Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Friday, November 10, 2017 11:27
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: Re: [EXT] Re: [lng-odp] classifier with pktio in ODP_PKTIN_
a mistake in the documentation or this combination should be
supported?
Liron
-Original Message-
From: Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Friday, November 10, 2017 07:18
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: [EXT] Re: [lng-odp] classifier wit
Hi,
I'm trying to understand how odp-classifier can work with PKTIO in
ODP_PKTIN_MODE_QUEUE mode, as this combination is allow in the API.
When configuring PKTIO in ODP_PKTIN_MODE_QUEUE then application should call
'odp_pktin_event_queue' to retrieve the odp-queues.
When application create a cos
Hi,
When I try to use either 'ODPH_IPPROTO_ICMPv4' in my code then checkpatch is
failing on
'CHECK: Avoid CamelCase: '.
Are those kind of 'check' errors can be ignored?
Maybe it will be better if you change 'ODPH_IPPROTO_ICMPv4' to
'ODPH_IPPROTO_ICMPV4' same as 'ODPH_ETHTYPE_IPV4'.
Thanks,
Lir
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 support for Ingress Metering/Policing
>> (RFC 2697, RFC2698) in future releases?
>>
>> Regards,
>> Liron
>>
issue with GCC5.3.1 I currently removed the new lines that add
latomic to the game.
Liron
From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Wednesday, October 25, 2017 23:42
To: Liron Himi
Cc: Brian Brooks ; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [EXT] Re: ODP1.15 with gcc-
linaro.org]
Sent: Tuesday, October 24, 2017 23:34
To: Liron Himi
Subject: Re: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1
Hi Liron,
I am not familiar with your crosstools environment. That is why I asked if
support for libatomic needs to be enabled.
The ODP build will simply try to -latom
Hi,
Is there any intention to add support for Ingress Metering/Policing (RFC 2697,
RFC2698) in future releases?
Regards,
Liron
Hi Brian,
I attached full configure output.
Liron
-Original Message-
From: Brian Brooks [mailto:brian.bro...@linaro.org]
Sent: Wednesday, October 18, 2017 18:50
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1
External Email
Hi,
We are using 'gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu' as our
tool-chain.
When I compile ODP1.15 with it I get a lot of:
'libtool: warning: library
'/home/userlab/work/crosstools/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/lib64/libatomic.la'
was moved.'
T
Hi,
I started to implement odp-classification based on our HW. As we also provide
the linux-generic PKTIOs support it seems we also need to provide the
linux-generic classification support (As a pure SW based implementation). But
there is no framework, as exist for PKTIO, to support various typ
Hi,
See comments inline
-Original Message-
From: Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Tuesday, October 03, 2017 21:13
To: Bill Fischofer
Cc: Liron Himi ; lng-odp@lists.linaro.org
Subject: Re: [EXT] Re: [lng-odp] odp_pktin_queue_param_t - classifier_enable
hofer [mailto:bill.fischo...@linaro.org]
Sent: Monday, October 02, 2017 14:52
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: [EXT] Re: [lng-odp] odp_pktin_queue_param_t - classifier_enable &
num_queues
External Email
Thanks Liron. This appears to be a bu
Hi,
According to the API if 'classifier_enable' is enabled than 'num_queues' and
'queue_param' should be ignored.
But looking at linux-generic implementation those parameters are always being
checked regardless of 'classifier_enable' value.
'classifier_enable' is actually ignore at linux-generic
: Thursday, August 10, 2017 19:45
To: Liron Himi ; lng-odp@lists.linaro.org
Cc: Petri Savolainen ; Elo, Matias (Nokia -
FI/Espoo)
Subject: [EXT] Re: [lng-odp] ODP1.15 buffer alignment issue
External Email
--
On 08/08/17 09:49, Liron
See comments inline in particular the change in RED
From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Tuesday, August 08, 2017 22:57
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: Re: [EXT] Re: [lng-odp] Parser configuration
On Tue, Aug 8, 2017 at 2:29 PM, Liron Himi
See comments inline
Liron
From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Tuesday, August 08, 2017 22:07
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: [EXT] Re: [lng-odp] Parser configuration
External Email
On Tue, Aug 8, 2017 at 1:43 PM
Hi,
I have a query regarding the new parser configuration.
Let's say application set it to 'ODP_PKTIO_PARSER_LAYER_L2', does it means that
the platform implementation must parse and recognize all eth-type that have ODP
API such as ARP,VLAN, etc.? same for ICMP, etc for L3?
I'm asking it as I tr
gt; This is part of the latest pool restructure code contributed by Nokia.
> If you'd like to join the ODP public call tomorrow at 15:00 UTC we can
> discuss this then.
>
> On Mon, Aug 7, 2017 at 8:57 AM, Liron Himi wrote:
>
>> Hi,
>>
>> I'm trying to mov
Hi,
I'm trying to move to odp1.15 and encounter with an buffer alignment issue.
It seems that linux-generic implementation make sure that the data address is
align with the requested alignment and not the buffer address itself (look at
the code sniped below).
On ODP1.11 (the current version we u
IO?
Liron
From: Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Thursday, July 27, 2017 04:48
To: Liron Himi
Cc: lng-odp@lists.linaro.org
Subject: [EXT] Re: [lng-odp] PKTIO and classification
External Email
On 26 July 2017 at 01:24, Liron Himi
Hi,
I have a few questions/clarifications regarding classification in PKTIO:
1. As part of the 'odp_pktin_queue_param_t' application should set
'classifier_enable' to '1' if classification support is wanted. Is that correct?
2. If #1 is correct, then why I can't see in the classific
Hi,
I'm running 'pktio_test_statistics_counters' and it failed on 'in_octets' check.
The root cause for the failure related to the FCS bytes.
My counter adds those bytes whereas the validation test check for the original
packet length.
According to the API those counters should count the whole pa
32 matches
Mail list logo