Re: [lng-odp] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement reference apis

Hi, I took a look at the packet references and it seems to me that either the implementation is a bit racy or I confused myself when reading the code. Or maybe I got the intended concurrency semantics of the packet references wrong? My first issue is that packet_free() may access freed packet hea

Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: packet: avoid race condition in packet_free processing

Hi, I do not think this really fixes the problem. If we ignore memory ordering issues for now, I think this would fix the problem that unshared_len would be modified after the packet has been freed (since now the current thread keeps its own reference over the unshared_len modification). Howeve

Re: [lng-odp] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement reference apis

Hi, Comments below. Janne > -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Friday, February 17, 2017 10:39 PM > To: Peltonen, Janne (Nokia - FI/Espoo) > Cc: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [API-NEXT

Re: [lng-odp] [PATCH] linux-gen: abi: fix include/odp/api/abi symlink creation

> > install-data-hook: > > if [ -h $(prefix)/include/odp/api/abi ]; then \ > > - : \ > > + : ; \ > > else \ > > $(LN_S) -rf $(prefix)/include/odp/arch/@ARCH_ABI@/odp/api/abi \ > > $(prefix)/include/odp/api/abi; \ > > Which bash are you

[lng-odp] Linking problem with --disable-abi-compat

Hi, I have hard time getting the following fine ODP application linked against the shared ODP library when ODP has been configured with --disable-abi-compat. It seems to me that the problem is in the 'local' binding of the _odp_packet_inline symbol in the .so, caused by the -fvisibility=hidden arg

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

Hi, > > + > > + /** Outer headers for inline output operation > > +* > > +* Outbound inline IPSEC operation uses this information to > > prepend > > +* outer headers to the IPSEC packet before sending it out. > > +*/ > > + struct { > > +

Re: [lng-odp] [API-NEXT PATCH v2 1/3] api: ipsec: extend lookaside API

> >  /** > > + * Disable IPSEC SA > > + * > > + * Application must use this call to disable a SA before destroying it. > > The call > > + * marks the SA disabled, so that IPSEC implementation stops using it. For > > + * example, inbound SPI lookups will not match any more. Application must > > +

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

Hi, A few quick comments below. Petri will probably comment the other points. Janne > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil > Agarwal > Sent: Thursday, March 23, 2017 2:02 PM > To: Petri Savolainen ; lng-odp@lists.linaro

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

> > This is part of odp_ipsec_sa_param_t, so lookup config is per SA. > > Does that mean that both SPI lookup and DEST ADDR lookup are mandatory? > Is there a reason lookup mode is per SA? The lookup mode is per SA to make it possible to have SAs for which not ODP but the application performs the

Re: [lng-odp] odp_ipsec_result behaviour

Hi, > - odp_ipsec_result() would change buffer type from IPSEC_RESULT to > PACKET, extract ipsec_op_result, etc. After this operation original > event is unsuitable for further operations. An added complication with ODP IPsec is fragmentation offload that can cause multiple result packets for o

Re: [lng-odp] [API-NEXT PATCH v2 00/16] A scalable software scheduler

Hi, On Thu, Apr 6, 2017 at 1:46 PM, Bill Fischofer wrote: > On Thu, Apr 6, 2017 at 1:32 PM, Ola Liljedahl > wrote: > > On 6 April 2017 at 13:48, Jerin Jacob > > wrote: > >> We see ORDERED->ATOMIC as main use case for basic packet forward.Stage > >> 1(ORDERED) to process on N cores and Stage

Re: [lng-odp] [API-NEXT PATCH] abi: event: add ODP_EVENT_IPSEC_STATUS

: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Friday, April 07, 2017 3:53 PM > To: Peltonen, Janne (Nokia - FI/Espoo) > Cc: lng-odp-forward > Subject: Re: [lng-odp] [API-NEXT PATCH] abi: event: add ODP_EVENT_IPSEC_STATUS > > On Fri, Apr 7, 2017 at 4:54 AM, Janne Peltonen

Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

Hi, > > Shally - enque in order-of-completion or in-order-submission? What does > > this mean in- > > context of ipsec? > > In general, there is bit of confusion when we are using terms async in ODP > > context here. > > It imply that queue is used to output events. an async implementation can

Re: [lng-odp] [API-NEXT PATCH v2 00/16] A scalable software scheduler

Hi, Ola Liljedahl <mailto:ola.liljed...@linaro.org> wrote: > Peltonen, Janne (Nokia - FI/Espoo) <mailto:janne.pelto...@nokia.com> wrote: > > In an IPsec GW (as a use case example) one might want to do all > > stateless processing (like ingress and egress IP pr

[lng-odp] IPsec API: signaling lifetime expiration

[Moving the discussion to the ODP list] > > Bogdan: I wonder why ODP did not considered to signal SA expiry as a status > > event (like > ODP_IPSEC_STATUS_SA_DISABLE)... meaning, what if there is no packet? > > This is an ODP question and that discussion should be moved to the ODP > mailing list

Re: [lng-odp] [API-NEXT][RFC][rebased] linux-gen: ipsec: draft IPsec implementation

Hi, Some comments on the patch: > >> - No tunnel support > >> - No header modification according to RFCs There is some tunneling and header modification code in the patch. Now it is not easy to tell which part of the code is supposed to work and which not. Other limitations include: There is n

Re: [lng-odp] [API-NEXT][RFC][rebased] linux-gen: ipsec: draft IPsec implementation

Hi, > >> + /* Setup parameters and call crypto library to create session */ > >> + crypto_param.op = (ODP_IPSEC_DIR_INBOUND == param->dir) ? > >> + ODP_CRYPTO_OP_DECODE : > >> + ODP_CRYPTO_OP_ENCODE; > >> + crypto_param.auth_cipher_text

Re: [lng-odp] [API-NEXT PATCH v2 00/16] A scalable software scheduler

Ola Liljedahl [mailto:ola.liljed...@linaro.org] wrote: > > On 10 April 2017 at 10:56, Peltonen, Janne (Nokia - FI/Espoo) > wrote: > > Hi, > > > > Ola Liljedahl <mailto:ola.liljed...@linaro.org> wrote: > >> Peltonen, Janne (Nokia - FI/Espoo) <mailto:

Re: [lng-odp] [PATCH v2] linux-generic: crypto: properly handle errors in packet copy

Hi, > > There is connected interesting question, which should be though wrt. all > 'packet-consuming' functions. Should such functions always consume and > free incoming packet? IOW: > > - odp_crypto_operation() returned -1. Should the app free inbound > packet afterwards? The API spec is not

Re: [lng-odp] [API-NEXT PATCH 8/8] linux-gen: time: use hw time counter when available

> > odp_sched_latency currently uses clock_gettime. It is my understanding > > that clock_gettime does not have the over head of the system call. Can > > you elaborate more on the 'improved significantly' part? > > > > clock_gettime() uses the same TSC, but when you profile it with perf you can >

Re: [lng-odp] [PATCH] linux-generic: rwlock: fix odp_rwlock_read_trylock()

That does not work. Since the value of cnt is not checked, the code would happily take the lock even when a writer already has it. Janne > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Github > ODP bot > Sent: Wednesday, April 26, 2017

Re: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

Hi, > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil > Agarwal > Sent: Friday, April 28, 2017 9:50 AM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support > sNIC > implementation. >

Re: [lng-odp] [[RFCv2] 2/4] api: ipsec: add default queue for outbound events

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Dmitry > Eremin- > Solenikov > Sent: Friday, April 28, 2017 3:44 AM > To: Bill Fischofer > Cc: lng-odp-forward > Subject: Re: [lng-odp] [[RFCv2] 2/4] api: ipsec: add default queue for > outboun

Re: [lng-odp] [[RFCv2] 3/4] api: ipsec: change semantics of odp_ipsec_result function

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill > Fischofer > Sent: Friday, April 28, 2017 4:06 AM > To: Dmitry Eremin-Solenikov > Cc: lng-odp-forward > Subject: Re: [lng-odp] [[RFCv2] 3/4] api: ipsec: change semantics of > odp_ipsec_res

Re: [lng-odp] IPsec SA disabling

Hi, > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Dmitry > Eremin- > Solenikov > Sent: Friday, April 28, 2017 11:59 AM > To: lng-odp-forward > Subject: [lng-odp] IPsec SA disabling > > Hello, > > While responding to Janne's email, I've come

Re: [lng-odp] IPsec SA disabling

nal Message- > From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] > Sent: Friday, April 28, 2017 4:03 PM > To: Bala Manoharan > Cc: Peltonen, Janne (Nokia - FI/Espoo) ; > lng-odp-forward o...@lists.linaro.org> > Subject: Re: [lng-odp] IPsec SA disabling

Re: [lng-odp] [[RFCv2] 3/4] api: ipsec: change semantics of odp_ipsec_result function

Bill Fischofer [mailto:bill.fischo...@linaro.org] wrote: > On Fri, Apr 28, 2017 at 5:44 AM, Dmitry Eremin-Solenikov < > dmitry.ereminsolenikov at linaro.org> wrote: > > > On 28.04.2017 12:03, Peltonen, Janne (Nokia - FI/Espoo) wrote: > > > > > >> -

Re: [lng-odp] [PATCH 3/3] linux-generic: classification: implement packet hashing in classifier

Hi, > @@ -846,11 +897,91 @@ int cls_classify_packet(pktio_entry_t *entry, const > uint8_t *base, > > *pool = cos->s.pool; > pkt_hdr->p.input_flags.dst_queue = 1; > - pkt_hdr->dst_queue = cos->s.queue->s.handle; > > + if (!cos->s.queue_group) { > + pkt_hdr->dst_qu

Re: [lng-odp] [PATCH 3/4] linux-generic: crypto: add SHA-1 authentication support

Hi, I think there is a problem or ambiguity in the ODP API spec regarding the truncation of the HMAC output. According to RFC 2104 the terminology goes so that HMAC-{hash-func} (e.g. HMAC-SHA-512) means the HMAC with the full, non-truncated output and HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-25

Re: [lng-odp] [PATCH 3/4] linux-generic: crypto: add SHA-1 authentication support

Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] wrote: > > On 03.05.2017 17:17, Peltonen, Janne (Nokia - FI/Espoo) wrote: > > Hi, > > > > I think there is a problem or ambiguity in the ODP API spec regarding > > the truncation of the HMAC output.

Re: [lng-odp] IPsec limits support

Bill Fischofer wrote: > On Thu, May 4, 2017 at 11:44 AM, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > > > On 04.05.2017 19:35, Bill Fischofer wrote: > > > > > > > > > On Thu, May 4, 2017 at 11:25 AM, Dmitry Eremin-Solenikov > > > > >

Re: [lng-odp] IPsec limits support

nal Message- > From: Peltonen, Janne (Nokia - FI/Espoo) > Sent: Friday, May 05, 2017 11:37 AM > To: Bill Fischofer ; Dmitry Eremin-Solenikov > > Cc: lng-odp-forward > Subject: RE: [lng-odp] IPsec limits support > > > Bill Fischofer wrote: > > On Thu, Ma

Re: [lng-odp] [PATCH API-NEXT v1 1/2] api: ipsec: add soft limit expiration event

If this ends up being the selected solution, then I think there needs to be a bit more documentation in the API on what this event means and when it will come. And maybe the application wants to know which of the limits was reached. Janne > -Original Message- > From: lng-odp [mail

Re: [lng-odp] Suspected SPAM - Re: [PATCH API-NEXT v1 2/2] api: ipsec: move soft limits expiration to flags, rather than errors

There is perhaps some ambiguity now in the API on whether expired soft lifetime means that a packet is not "successfully processed", which in turn determines whether inline mode outbound packets get sent directly out. Having the life time expiration in the error field could be interpreted to imply

Re: [lng-odp] Packet validation question

Dmitry Eremin-Solenikov wrote: > Another generic question regarding ODP. If the package gets passed to > IPsec API, should I trust e.g. IP header values? IOW, can I assume, that > ip->tot_len + l3_offset is equal to odp_packet_len(), or is that an error? Good question. I think there are several s

Re: [lng-odp] Packet validation question

Bill Fischofer wrote: > On Fri, May 12, 2017 at 6:27 AM, Peltonen, Janne (Nokia - FI/Espoo) > wrote: > > Dmitry Eremin-Solenikov wrote: > >> Another generic question regarding ODP. If the package gets passed to > >> IPsec API, should I trust e.g. IP header values? I

Re: [lng-odp] [PATCH API-NEXT v4 2/10] api: ipsec: note that soft_exp bits are set only once

Dmitry Eremin-Solenikov wrote: > > Add an explicit note telling that soft_exp bits are set only once, for > the packet actually crossing the boundary. They will not be set for > further packets. Isn't this perhaps a bit too restrictive on implementations that may process packets in parallel and

Re: [lng-odp] [RFC] dpdk: enable hardware checksum support

Bogdan Pricope wrote: > On 10 May 2017 at 20:06, Savolainen, Petri (Nokia - FI/Espoo) > wrote: > > > > > >> -Original Message- > >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > >> Bogdan Pricope > >> Sent: Wednesday, May 10, 2017 4:50 PM > >> To: lng-odp@lists.li

[lng-odp] Packet order lost when enqueuing to pktout queue

Hi, It seems that the packet enqueue order to pktout queues does not necessarily match the dequeue order of an ordered source queue. Enqueue to a normal queue ensures the right order by interacting with the scheduler in enq_multi() but the pktout specific enqueue implementation pktout_enqueue() d

Re: [lng-odp] IPsec crypto algorithms summary

Hi, The IPsec and IKE document roadmap (RFC 6071) is a good summary about the required crypto-algorithms, among other things. Bill Fischofer wrote: > On Wed, May 17, 2017 at 7:07 PM, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > > > I think, linux-generic should support

Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet checksum control

That patch is in the api-next branch now. The checksum insertion override has basically three different states: 1) Override not set, i.e. odp_packet_l{3,4}_chksum_insert() not called for the packet 2) Override set: do not insert checksum 3) Override set: insert checksum If the override is set, t

Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet checksum control

um => depends on “HW Supported” That is just one possible way to define the behavior. Now it is left ambiguous in the API. Janne > -Original Message- > From: Bogdan Pricope [mailto:bogdan.pric...@linaro.org] > Sent: Friday, May 19, 2017 11:07 AM > To: Peltonen, Janne

Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet checksum control

Bill Fischofer wrote: > If the pktout configuration says "don't checksum" and the per-packet bits > say "do checksum", then it's up to the implementation to insert the requested > checksum or else fail the odp_pktout_send() request. The API spec says the following, implying that it is perfectly

Re: [lng-odp] [PATCH] linux-gen: sched: fix ordered enqueue to pktout queue

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Matias > Elo > Sent: Monday, May 22, 2017 12:39 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH] linux-gen: sched: fix ordered enqueue to pktout > queue > > Make sure packet order i

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

> +static int ord_enq_multi(uint32_t queue_index, void *p_buf_hdr[], > + int num, int *ret) > +{ > + (void)queue_index; > + (void)p_buf_hdr; > + (void)num; > + (void)ret; > + return 0; > +} How is packet order maintained when enqueuing packets read from an

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

Honnappa Nagarahalli wrote: > On 23 May 2017 at 09:49, Peltonen, Janne (Nokia - FI/Espoo) > wrote: > > > >> +static int ord_enq_multi(uint32_t queue_index, void *p_buf_hdr[], > >> + int num, int *ret) > >> +{ > >> +

Re: [lng-odp] Summary of Expiration Discussion

Bill Fischofer wrote: > > The following data items MUST be in the SAD: But that does not necessarily mean that they need to be in the ODP SA. > With this background, it's clear that should we choose to remove > time-based expiration from the ODP IPsec API spec we would have an > incomplete IPsec

Re: [lng-odp] Summary of Expiration Discussion

> -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Friday, May 26, 2017 5:04 PM > To: Peltonen, Janne (Nokia - FI/Espoo) > Cc: lng-odp-forward > Subject: Re: [lng-odp] Summary of Expiration Discussion > > On Wed, May 24, 2

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

Ola Liljedahl wrote: > On 23/05/2017, 16:49, "Peltonen, Janne (Nokia - FI/Espoo)" > wrote: > > > > > >> +static int ord_enq_multi(uint32_t queue_index, void *p_buf_hdr[], > >> + int num, int *ret) > >> +{ > >>

Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v6 6/6] Add scalable scheduler

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Savolainen, Petri > (Nokia - FI/Espoo) > Sent: Friday, June 02, 2017 1:18 PM > To: Honnappa Nagarahalli ; Ola Liljedahl > > Cc: Elo, Matias (Nokia - FI/Espoo) ; nd ; > Kevin Wang > ; Honnappa

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola > Liljedahl > Sent: Friday, June 02, 2017 1:41 PM > To: Savolainen, Petri (Nokia - FI/Espoo) ; > Honnappa > Nagarahalli > Cc: Elo, Matias (Nokia - FI/Espoo) ; nd ; > Kevin Wang > ; Honnappa

Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v6 6/6] Add scalable scheduler

> -Original Message- > From: Ola Liljedahl [mailto:ola.liljed...@arm.com] > Sent: Friday, June 02, 2017 1:54 PM > To: Peltonen, Janne (Nokia - FI/Espoo) ; > Savolainen, Petri > (Nokia - FI/Espoo) ; Honnappa Nagarahalli > > Cc: Elo, Matias (Nokia - FI/Esp

Re: [lng-odp] [API-NEXT PATCH] linux-gen: queue: clean up after modular interface

Honnappa Nagarahalli wrote: > On 12 June 2017 at 06:11, Petri Savolainen > wrote: > > Clean up function and parameter naming after modular interface > > patch. Queue_t type is referred as "queue internal": queue_int or > > q_int. Term "handle" is reserved for API level handles (e.g. > > odp_queu

Re: [lng-odp] [API-NEXTv2] api: ipsec: reorganize odp_ipsec_sa_param_t structure based on SA direction

> >> /** Initial sequence number */ > >> uint64_t seq; > > > > This may be moved to outbound struct. > > I thought the same.. yet, some say is needed on inbound as well ("to > know from where to start expecting frames") a.k.a. antireplay > mechanism. It is not needed in inbound since

Re: [lng-odp] [PATCH] api:crypto: Adding IPSEC protocol APIs.

Hi, Is this work toward a look-a-side IPsec offload or toward inline IPsec offload? How would the application offer packets to IPsec processing and how would it get the processed packets back and how would it know which policy and session was applied to the packet? What happens when an outbound p

Re: [lng-odp] IpSec protocol offload proposal

Hi, A few questions and comments: Can there be VLAN tags in the received packets? How do I know what L2 headers a received packet originally had and through which interface it was received? How do I fall back to look-a-side mode when e.g. an IPsec packet came in inside other tunnel (e.g. VxLAN,

Re: [lng-odp] IpSec protocol offload proposal

Hi, Comment inline: > From: Bala Manoharan [mailto:bala.manoha...@linaro.org] > Comments inline... > > On 27 September 2016 at 10:07, Peltonen, Janne (Nokia - FI/Espoo) > wrote: > > Hi, > > > > A few questions and comments: > > > > Can there be VLA

Re: [lng-odp] Fwd: IpSec protocol offload proposal

Bill > Fischofer > Sent: Friday, September 30, 2016 12:47 AM > To: LNG ODP Mailman List > Subject: [lng-odp] Fwd: IpSec protocol offload proposal > > I hit reply rather than reply all on this. Sorry, this should have been a > reply to the mailing list. > > Bill >

Re: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

Hi, > > +typedef struct odp_ipsec_lifetime_t { > > + /** Soft expiry limits for the session */ > > + struct { > > + /** Limit in seconds */ > > + uint64_t sec; > > Does expiry time mean the ADD_TIME -Time calculated when the policy is > added to database or

Re: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

Hi, > What will be the total number of SA in the system? Will it be around 100K? Yes, the API should work with that many SAs. > If that is the case IMO it might be better to add a "context_packet" > which could be copied to the output packet instead of having 100K > different queues? I think t

Re: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

Hi, > > + /** IPv6 Differentiated Services Code Point */ > > + uint8_t dscp; > > > > IPv6 does not use a DSCP. The field is called Traffic Class in IPv6 so this > should be uint8_t traffic_class; RFC 2474 renames IPv4 ToS and IPv6 traffic class fields

Re: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

Comments below. > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala > Manoharan > Sent: Wednesday, November 16, 2016 11:16 AM > To: Savolainen, Petri (Nokia - FI/Espoo) > > Cc: lng-odp-forward > Subject: Re: [lng-odp] [API-NEXT DRAFT] api: i

Re: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API

Hi, > I am wonder how will be calculate lifetime in bytes for asynchronous > inbound operations and how the application can figure it out from output > packets: it is only output packet data or should contain ESP header/trailer > + outer IP header? RFC 4301 says this about byte based SA lifetime

Re: [lng-odp] clarification of pktout checksum offload feature

Hi, > > There is also a second thing: how to disable checksum calculation > > per-packet? > We've talked about doing this but currently have no APIs for exposing this > capability. Do you have a use case in mind? The use cases include many UDP based tunneling protocols that want to disable check

Re: [lng-odp] [openfastpath] Performance issues found in OFP 2.0 upon integration into Memcached

then another matter. Janne > -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Thursday, January 26, 2017 3:59 PM > To: Geoffrey Blake > Cc: Mike Holmes ; Sorin Vultureanu > ; > Peltonen, Janne (Nokia - FI/Espoo) ; Bogdan Pr

Re: [lng-odp] [API-NEXT PATCH 1/9] api: ipsec: add salt parameter

Dmitry Eremin-Solenikov wrote: > On 11.07.2017 15:31, Petri Savolainen wrote: > > Added a parameter for passing salt for AES GCM. Currently, > > only option for length is 4 bytes, but later on other algorithms > > may need more/less salt data. > > > > Signed-off-by: Petri Savolainen > > --- > > i

Re: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the MAC address and MTU size.

Hi, ODP API should somewhere define what exactly MTU means in the context of ODP. One can guess that transmission and reception of L2 frames larger than the configured MTU is not guaranteed to succeed, but which bytes are taken into account? For instance, is Ethernet FCS counted towards the MTU?

Re: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the MAC address and MTU size.

. Janne From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: Friday, July 14, 2017 5:39 PM To: Bogdan Pricope ; Petri Savolainen Cc: Narayana Prasad Athreya ; Peltonen, Janne (Nokia - FI/Espoo) ; mcha...@cavium.com; lng-odp@lists.linaro.org; pathr...@cavium.com; vattun...@cavium.com; sve

Re: [lng-odp] [EXT] Re: ODP1.15 buffer alignment issue

Hi, The alignment must be for the buffer start address that is returned by odp_buffer_addr(), since that is the only memory address visible in the buffer API. The internal representation of the buffer and the associated metadata is not visible to the application through the API so the alignment o

Re: [lng-odp] [PATCH API-NEXT v1 1/1] api:pktio: Adds MTU set function.

Hi, The API patch should make it more clear what MTU means in the context of ODP packet I/O. I think it should mean something close to this: ODP must be able to send and receive packets up to the MTU size succesfully. Packets larger than the MTU may get dropped or may get received successfully (

Re: [lng-odp] [PATCH API-NEXT v5 1/1] API:IPSEC: IPSEC events may be reported synchronously.

Hi, Why is this change needed or preferred over the current API? I would guess that many applications that use inline or asynchronous mode need an end marker in the SA queue so that they know when they can free their own per-SA state and destroy the ODP SA (i.e. when all events for the SA being

Re: [lng-odp] [PATCH API-NEXT v5 1/1] API:IPSEC: IPSEC events may be reported synchronously.

hen it would be able to postpone the destroying of an SA until all events for the SA have been fully handled. Janne From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: Monday, August 14, 2017 9:19 PM To: Peltonen, Janne (Nokia - FI/Espoo) Cc: Github ODP b

Re: [lng-odp] [PATCH API-NEXT v5 1/1] API:IPSEC: IPSEC events may be reported synchronously.

:34 PM To: Peltonen, Janne (Nokia - FI/Espoo) Cc: Github ODP bot ; lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH API-NEXT v5 1/1] API:IPSEC: IPSEC events may be reported synchronously. On Mon, Aug 14, 2017 at 11:42 PM, Peltonen, Janne (Nokia - FI/Espoo) mailto:janne.pelto...@nokia

Re: [lng-odp] IPsec API finialization

Hi, Comments below: Bill Fischofer wrote: > As discussed during today's ARCH call, we need to close on the > remaining IPsec confusion surrounding the definition of > odp_ipsec_sa_disable(). > > The main scenario that this API is designed to address, from an > application standpoint is as follow

Re: [lng-odp] IPsec API finialization

Bill Fischofer [mailto:bill.fischo...@linaro.org] wrote: > On Fri, Sep 8, 2017 at 6:10 AM, Janne Peltonen > wrote: > > > > > > On Fri, 8 Sep 2017, Nikhil Agarwal wrote: > >> On 7 September 2017 at 14:09, Peltonen, Janne (Nokia - FI/Espoo) > >

Re: [lng-odp] IPsec fragmentation ambiguity

The odp_ipsec_error_t, which is part of packet result includes the following error bit: /** Packet does not fit into the given MTU size */ uint32_t mtu : 1; In ODP_IPSEC_FRAG_CHECK mode an operation fails and indicates the mtu error if

Re: [lng-odp] [PATCH API-NEXT v1 1/3] api: ipsec: rework ODP_IPSEC_SA_DISABLE into packet error

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 > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH API-NEXT v1 1/3] api: ipsec: rework > ODP_IPSEC_SA_DISABL

Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata

As discussed offline with Petri, I feel that it would be useful to let the ODP implementation tell from which packet offset the sum calculation starts (or even let the implementation specify the range, i.e. also the end). The rationale is that even though starting from L4 offset is reasonable from

[lng-odp] IPsec and crypto performance and OpenSSL

Hi, When playing with IPsec I noticed that the Linux generic ODP implementation creates a separate OpenSSL crypto context for each crypto-operation as opposed to doing it at ODP crypto session creation. With IPsec this adds a lot of overhead for every packet processed and significantly reduces pac

Re: [lng-odp] Suspected SPAM - Re: IPsec and crypto performance and OpenSSL

; allocates/destroys per thread contexts in array in that shm. I think > > that > > > > has to work. > > > > > > The problem lies in OpenSSL 1.1 "opaque structures" approach. They > > stopped > > > providing exact struct definitions which can be e

Re: [lng-odp] IPsec and crypto performance and OpenSSL

nne (Nokia - FI/Espoo) > Cc: Savolainen, Petri (Nokia - FI/Espoo) ; Bill > Fischofer > ; lng-odp@lists.linaro.org > Subject: Re: Suspected SPAM - Re: [lng-odp] IPsec and crypto performance and > OpenSSL > > Hello, > > On 12 December 2017 at 12:38, Peltonen, Janne (No

Re: [lng-odp] IPsec and crypto performance and OpenSSL

Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] wrote: > On 12 December 2017 at 14:00, Peltonen, Janne (Nokia - FI/Espoo) > wrote: > >> Also note that this will break explicit IV support. > > > > Why so? The iv is set in every operation. > >

Re: [lng-odp] Inside Secure IPsec HW capabilities

Pascal Van Leeuwen wrote: > I get the impression that > the IPsec payload can just be random garbage, i.e. it doesn't have to decrypt > to anything > that makes sense and it doesn't have to authenticate properly (to facilitate > fast > generation of such packets by skipping actual cryptographic o

Re: [lng-odp] wrong push to master branch was reverted

My repo, to which I pulled from ODP before the odp-dpdk merge happened, has the following commit that has not disappeared from the ODP repo. Is it intentional? (btw, the commit comment of it may not be totally accurate anyway (i.e. does it really fix the bug)): Janne commit 273264b459d981

Re: [lng-odp] Compression API: hashing

. Janne From: Bill Fischofer Sent: Monday, December 10, 2018 11:27 PM To: Dmitry Eremin-Solenikov ; Peltonen, Janne (Nokia - FI/Espoo) Cc: lng-odp-forward Subject: Re: [lng-odp] Compression API: hashing I'd like to hear from Janne as to what OFP would prefer. I'll also add th