Re: [lng-odp] [RFC API-NEXT PATCH] Packet References and Composites

[Bala Manoharan]

This patch series could be split into two different parts as Reference
and Composite since IMO the Referencing part is straight forward and
might not need much discussion and could be be accepted sooner.

Regarding the concept of composite packets it would be appreciable to
provide some use-cases for this API.
The individual pieces of the composite could be referenced using a
different handle than the odp_packet_t in the same way we do for
segments. Since the idea is to utilize unique and shared sections
these sections could be referred using odp_buffer_t rather than
odp_packet_t.

Regards,
Bala
Regards,
Bala


On 7 January 2016 at 20:20, Bill Fischofer  wrote:
> Add two new concepts to ODP Packets: References and Composites
>
> This RFC proposes the addition of two new concepts to the ODP API: References
> and Composites. A reference is an alias to packet. References are either
> shared or nonshared. Changes to a shared reference are visible to all other
> shared reference to the same packet while changes to nonshared references are
> unique to that reference. References provide an efficient means of supporting
> things like multicast without the explicit use of reference counts, as
> underlying packet storage is only freed when the last reference to it is
> freed.
>
> References are intended to be used in conjunction with another new concept:
> Composites. A composite is a logical join between two packets that can then
> be manipulated as if they are a single packet. The intent of composites is to
> provide an efficient and implementation-independent means of creating and
> manipulating packets that consist of a combination of unique and shared
> sections. Typical use would be to have one or more unique headers prefixed to
> a common payload.
>
> Composites are created by pushing/pulling prefixes and suffixes. These
> routines create a new composite packet which has its own handle. Each of the
> component parts of composites are themelves ODP packets and continue to be
> manipulable via ODP APIs even while they are part of a composite.  References
> to each part of a composite via its own handle affect that part of the
> composite only but are visible when referencing the composite via its handle.
> Note that a composite handle is an implied reference to each of its component
> parts, so freeing a packet after it has been composited does not release the
> underlying storage associated with that part until the composite itself is
> freed or the freed part is removed from the composite.
>
> Bill Fischofer (1):
>   api: packet: add packet references and composites
>
>  include/odp/api/packet.h | 98 
> 
>  1 file changed, 98 insertions(+)
>
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC API-NEXT PATCH] api: packet: add packet segment manipulation

[Bala Manoharan]

Hi,


On 11 January 2016 at 19:17, Petri Savolainen
 wrote:
> Packet segments can be allocated/freed/multi-referenced.
> Segments data pointer and length can be modified (push/pull).
> Segments can be linked to packets when needed (can exist also
> when not connected to packets).
>
> TODO: Packet pool params need tuning for segment length
> configuration.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/packet.h | 82 
> +++-
>  1 file changed, 74 insertions(+), 8 deletions(-)
>
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 8651a47..7d315ba 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -118,6 +118,15 @@ int odp_packet_alloc_multi(odp_pool_t pool, uint32_t len,
>odp_packet_t pkt[], int num);
>
>  /**
> + * Create a new reference to the packet
> + *
> + * @param pkt   Packet handle
> + *
> + * @return New handle which refers to the input packet
> + */
> +odp_packet_t odp_packet_ref(odp_packet_t pkt);
> +
> +/**
>   * Free packet
>   *
>   * Frees the packet into the buffer pool it was allocated from.
> @@ -810,11 +819,44 @@ void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, 
> int8_t adj);
>   */
>
>  /**
> + * Allocate a new segment
> + *
> + * Allocates a new segment from the specified packet pool. The segment
> + * is initialized with data pointers and lengths set according to the
> + * specified len. All other segment metadata are set to their default values.
> + *
> + * @param pool  Pool handle
> + * @param len   Segment data length
> + *
> + * @return Handle of allocated packet
> + * @retval ODP_PACKET_SEG_INVALID  Segment could not be allocated
> + */
> +odp_packet_seg_t odp_packet_seg_alloc(odp_pool_t pool, uint32_t len);

IMO, we can update the statement that the maximum allocatable length
will be only one segment. ie the segment alloc always alloc one
segment from the pool and size will be equal to segment size.

> +
> +/**
> + * Free segment
> + *
> + * Frees the segment into the pool it was allocated from. Segment must not be
> + * linked into any packet.
> + *
> + * @param seg   Segment handle
> + */
> +void odp_packet_seg_free(odp_packet_seg_t seg);

IMO, the above function needs additional description as to what
happens when a packet where this segment is linked to is freed. if the
segment has only one reference then does odp_packet_free() basically
free the attached segment also.

> +
> +/**
> + * Create a new reference to the segment
> + *
> + * @param seg   Segment handle
> + *
> + * @return New handle which refers to the input segment
> + */
> +odp_packet_seg_t odp_packet_seg_ref(odp_packet_seg_t seg);
> +
> +/**
>   * Segment buffer address
>   *
>   * Returns start address of the segment.
>   *
> - * @param pkt  Packet handle
>   * @param seg  Segment handle
>   *
>   * @return  Start address of the segment
> @@ -822,28 +864,26 @@ void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, 
> int8_t adj);
>   *
>   * @see odp_packet_seg_buf_len()
>   */
> -void *odp_packet_seg_buf_addr(odp_packet_t pkt, odp_packet_seg_t seg);
> +void *odp_packet_seg_buf_addr(odp_packet_seg_t seg);
>
>  /**
>   * Segment buffer length
>   *
>   * Returns segment buffer length in bytes.
>   *
> - * @param pkt  Packet handle
>   * @param seg  Segment handle
>   *
>   * @return  Segment buffer length in bytes
>   *
>   * @see odp_packet_seg_buf_addr()
>   */
> -uint32_t odp_packet_seg_buf_len(odp_packet_t pkt, odp_packet_seg_t seg);
> +uint32_t odp_packet_seg_buf_len(odp_packet_seg_t seg);
>
>  /**
>   * Segment data pointer
>   *
>   * Returns pointer to the first byte of data in the segment.
>   *
> - * @param pkt  Packet handle
>   * @param seg  Segment handle
>   *
>   * @return  Pointer to the segment data
> @@ -851,21 +891,29 @@ uint32_t odp_packet_seg_buf_len(odp_packet_t pkt, 
> odp_packet_seg_t seg);
>   *
>   * @see odp_packet_seg_data_len()
>   */
> -void *odp_packet_seg_data(odp_packet_t pkt, odp_packet_seg_t seg);
> +void *odp_packet_seg_data(odp_packet_seg_t seg);
>
>  /**
>   * Segment data length
>   *
>   * Returns segment data length in bytes.
>   *
> - * @param pkt  Packet handle
>   * @param seg  Segment handle
>   *
>   * @return  Segment data length in bytes
>   *
>   * @see odp_packet_seg_data()
>   */
> -uint32_t odp_packet_seg_data_len(odp_packet_t pkt, odp_packet_seg_t seg);
> +uint32_t odp_packet_seg_data_len(odp_packet_seg_t seg);
> +
> +
> +void *odp_packet_seg_push_head(odp_packet_seg_t seg, uint32_t len);
> +
> +void *odp_packet_seg_pull_head(odp_packet_seg_t seg, uint32_t len);
> +
> +void *odp_packet_seg_push_tail(odp_packet_seg_t seg, uint32_t len);
> +
> +void *odp_packet_seg_pull_tail(odp_packet_seg_t seg, uint32_t len);

In the above APIs for push and pull at segment level it is better if
the application could pass the packet handle also since any change in
length of the segment will affec

[lng-odp] API-NEXT branch is broken

[Bala Manoharan]

Hi,

The api-next branch is broken after merge from master.
convert atomic_queue.svg atomic_queue.png
/bin/bash: convert: command not found
make[2]: *** [atomic_queue.png] Error 127

Regards,
Bala
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 3/5] validation: cls: test_pmr: don't create default input queue

[Bala Manoharan]

This patch does not apply maybe you need to rebase to HEAD.

Regards,
Bala
Regards,
Bala


On 12 January 2016 at 23:41, Ivan Khoronzhuk  wrote:
> There is no need to create default input queue for pktio if
> default CoS is assigned.
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  .../classification/odp_classification_test_pmr.c   | 54 
> --
>  1 file changed, 54 deletions(-)
>
> diff --git a/test/validation/classification/odp_classification_test_pmr.c 
> b/test/validation/classification/odp_classification_test_pmr.c
> index 75d2a95..0b3f279 100644
> --- a/test/validation/classification/odp_classification_test_pmr.c
> +++ b/test/validation/classification/odp_classification_test_pmr.c
> @@ -55,39 +55,6 @@ odp_pktio_t create_pktio(odp_queue_type_t q_type)
> return pktio;
>  }
>
> -int create_default_inq(odp_pktio_t pktio, odp_queue_type_t qtype)
> -{
> -   odp_queue_param_t qparam;
> -   odp_queue_t inq_def;
> -   char inq_name[ODP_QUEUE_NAME_LEN];
> -
> -   odp_queue_param_init(&qparam);
> -   qparam.sched.prio  = ODP_SCHED_PRIO_DEFAULT;
> -   qparam.sched.sync  = ODP_SCHED_SYNC_ATOMIC;
> -   qparam.sched.group = ODP_SCHED_GROUP_ALL;
> -
> -   snprintf(inq_name, sizeof(inq_name), "inq-pktio-%" PRIu64,
> -odp_pktio_to_u64(pktio));
> -   inq_def = odp_queue_lookup(inq_name);
> -   if (inq_def == ODP_QUEUE_INVALID)
> -   inq_def = odp_queue_create(
> -   inq_name,
> -   ODP_QUEUE_TYPE_PKTIN,
> -   qtype == ODP_QUEUE_TYPE_POLL ? NULL : 
> &qparam);
> -
> -   CU_ASSERT_FATAL(inq_def != ODP_QUEUE_INVALID);
> -
> -   if (0 > odp_pktio_inq_setdef(pktio, inq_def))
> -   return -1;
> -
> -   if (odp_pktio_start(pktio)) {
> -   fprintf(stderr, "unable to start loop\n");
> -   return -1;
> -   }
> -
> -   return 0;
> -}
> -
>  void configure_default_cos(odp_pktio_t pktio, odp_cos_t *cos,
>odp_queue_t *queue, odp_pool_t *pool)
>  {
> @@ -163,8 +130,6 @@ void classification_test_pmr_term_tcp_dport(void)
>
> pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
> CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
> -   CU_ASSERT(retval == 0);
>
> configure_default_cos(pktio, &default_cos,
>   &default_queue, &default_pool);
> @@ -237,7 +202,6 @@ void classification_test_pmr_term_tcp_dport(void)
> odp_cos_destroy(cos);
> odp_cos_destroy(default_cos);
> odp_pmr_destroy(pmr);
> -   destroy_inq(pktio);
> odp_queue_destroy(queue);
> odp_queue_destroy(default_queue);
> odp_pool_destroy(pool);
> @@ -273,8 +237,6 @@ void classification_test_pmr_term_tcp_sport(void)
>
> pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
> CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
> -   CU_ASSERT(retval == 0);
>
> configure_default_cos(pktio, &default_cos,
>   &default_queue, &default_pool);
> @@ -344,7 +306,6 @@ void classification_test_pmr_term_tcp_sport(void)
> odp_cos_destroy(cos);
> odp_cos_destroy(default_cos);
> odp_pmr_destroy(pmr);
> -   destroy_inq(pktio);
> odp_pool_destroy(default_pool);
> odp_pool_destroy(pool);
> odp_queue_destroy(queue);
> @@ -380,8 +341,6 @@ void classification_test_pmr_term_udp_dport(void)
>
> pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
> CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
> -   CU_ASSERT(retval == 0);
>
> configure_default_cos(pktio, &default_cos,
>   &default_queue, &default_pool);
> @@ -452,7 +411,6 @@ void classification_test_pmr_term_udp_dport(void)
> odp_cos_destroy(cos);
> odp_cos_destroy(default_cos);
> odp_pmr_destroy(pmr);
> -   destroy_inq(pktio);
> odp_queue_destroy(queue);
> odp_queue_destroy(default_queue);
> odp_pool_destroy(default_pool);
> @@ -488,8 +446,6 @@ void classification_test_pmr_term_udp_sport(void)
>
> pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
> CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
> -   CU_ASSERT(retval == 0);
>
> configure_default_cos(pktio, &default_cos,
>   &default_queue, &default_pool);
> @@ -559,7 +515,6 @@ void classification_test_pmr_term_udp_sport(void)
> odp_cos_destroy(cos);
> odp_cos_destroy(default_cos);
> odp_pmr_destroy(pmr);
> -   destroy_inq(pktio);
> odp_pool_destroy(default_pool);
> odp_pool_destroy(pool);
> odp_queue_destr

Re: [lng-odp] [PATCH 0/5] validation: cls: correct tests a little

[Bala Manoharan]

Hi Ivan,

It would be better if you can send this patch on API-NEXT branch as I
said before I am working on API proposal to modify odp_pmr_create()
function syntax and it would be easy if we could modify your changes
to API-NEXT and then we can move it to master branch.

The patch 3 in your series is not applying on the master branch.
Further comments on each patch series.

Regards,
Bala
Regards,
Bala


On 12 January 2016 at 23:41, Ivan Khoronzhuk  wrote:
> This patch series corrects classification tests to be a little bit
> adoptive.
>
> Ivan Khoronzhuk (5):
>   validation: cls: adopt for supported l3 PMR
>   validation: cls: assign default CoS before creating chain
>   validation: cls: test_pmr: don't create default input queue
>   validation: cls: use correct MAC addresses
>   validation: cls: split pmr chain test
>
>  test/validation/classification/classification.h|  28 +--
>  .../classification/odp_classification_basic.c  |   4 +-
>  .../classification/odp_classification_common.c |  52 ++
>  .../classification/odp_classification_test_pmr.c   | 205 
> -
>  .../classification/odp_classification_tests.c  | 127 ++---
>  .../classification/odp_classification_testsuites.h |   2 +
>  6 files changed, 203 insertions(+), 215 deletions(-)
>
> --
> 1.9.1
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 5/5] validation: cls: split pmr chain test

[Bala Manoharan]

The idea behind this suite is to have a mechanism to test the
behaviour of the system after applying all the different PMR, default
CoS, error CoS and L2 and L3 CoS values. your suggested changes tests
each and every configuration individually which defeats the idea of
the suite.
There is a dedicated suite to test individual PMR values behaviour.

Regards,
Bala


On 12 January 2016 at 23:41, Ivan Khoronzhuk  wrote:
> These tests are simple classification tests and better to see results
> for each of them separately.
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  test/validation/classification/classification.h| 22 ---
>  .../classification/odp_classification_tests.c  | 72 
> --
>  2 files changed, 38 insertions(+), 56 deletions(-)
>
> diff --git a/test/validation/classification/classification.h 
> b/test/validation/classification/classification.h
> index f363812..6d2e55f 100644
> --- a/test/validation/classification/classification.h
> +++ b/test/validation/classification/classification.h
> @@ -13,7 +13,6 @@
>  #define SHM_PKT_BUF_SIZE1024
>
>  /* Config values for Default CoS */
> -#define TEST_DEFAULT   1
>  #defineCLS_DEFAULT 0
>  #define CLS_DEFAULT_SADDR  "10.0.0.1/32"
>  #define CLS_DEFAULT_DADDR  "10.0.0.100/32"
> @@ -21,29 +20,24 @@
>  #define CLS_DEFAULT_DPORT  2048
>
>  /* Config values for Error CoS */
> -#define TEST_ERROR 1
>  #define CLS_ERROR  1
>
>  /* Config values for PMR_CHAIN */
> -#define TEST_PMR_CHAIN 1
>  #define CLS_PMR_CHAIN_SRC  2
>  #define CLS_PMR_CHAIN_DST  3
>  #define CLS_PMR_CHAIN_SADDR"10.0.0.5/32"
>  #define CLS_PMR_CHAIN_PORT 3000
>
>  /* Config values for PMR */
> -#define TEST_PMR   1
>  #define CLS_PMR4
>  #define CLS_PMR_PORT   4000
>
>  /* Config values for PMR SET */
> -#define TEST_PMR_SET   1
>  #define CLS_PMR_SET5
>  #define CLS_PMR_SET_SADDR  "10.0.0.6/32"
>  #define CLS_PMR_SET_PORT   5000
>
>  /* Config values for CoS L2 Priority */
> -#define TEST_L2_QOS1
>  #define CLS_L2_QOS_0   6
>  #define CLS_L2_QOS_MAX 5
>
> @@ -68,8 +62,20 @@ void classification_test_pktio_set_skip(void);
>  void classification_test_pktio_set_headroom(void);
>  void classification_test_pmr_terms_avail(void);
>  void classification_test_pmr_terms_cap(void);
> -void classification_test_pktio_configure(void);
> -void classification_test_pktio_test(void);
> +
> +void classification_test_configure_pktio_default_cos(void);
> +void classification_test_configure_pktio_error_cos(void);
> +void classification_test_configure_cls_pmr_chain(void);
> +void classification_test_configure_cos_with_l2_priority(void);
> +void classification_test_configure_pmr_cos(void);
> +void classification_test_configure_pktio_pmr_match_set_cos(void);
> +
> +void classification_test_pktio_default_cos(void);
> +void classification_test_pktio_error_cos(void);
> +void classification_test_cls_pmr_chain(void);
> +void classification_test_cos_with_l2_priority(void);
> +void classification_test_pmr_cos(void);
> +void classification_test_pktio_pmr_match_set_cos(void);
>
>  void classification_test_pmr_term_tcp_dport(void);
>  void classification_test_pmr_term_tcp_sport(void);
> diff --git a/test/validation/classification/odp_classification_tests.c 
> b/test/validation/classification/odp_classification_tests.c
> index 34fc570..482e2d0 100644
> --- a/test/validation/classification/odp_classification_tests.c
> +++ b/test/validation/classification/odp_classification_tests.c
> @@ -133,7 +133,7 @@ cls_create_packet(bool vlan, odp_atomic_u32_t *seq, bool 
> flag_udp)
> return pkt;
>  }
>
> -void configure_cls_pmr_chain(void)
> +void classification_test_configure_cls_pmr_chain(void)
>  {
> /* PKTIO --> PMR_SRC(SRC IP ADDR) --> PMR_DST (TCP SPORT) */
>
> @@ -230,7 +230,7 @@ void configure_cls_pmr_chain(void)
> CU_ASSERT(retval == 0);
>  }
>
> -void test_cls_pmr_chain(void)
> +void classification_test_cls_pmr_chain(void)
>  {
> odp_packet_t pkt;
> odph_ipv4hdr_t *ip;
> @@ -284,7 +284,7 @@ void test_cls_pmr_chain(void)
> odp_packet_free(pkt);
>  }
>
> -void configure_pktio_default_cos(void)
> +void classification_test_configure_pktio_default_cos(void)
>  {
> int retval;
> odp_queue_param_t qparam;
> @@ -318,7 +318,7 @@ void configure_pktio_default_cos(void)
> CU_ASSERT(retval == 0);
>  }
>
> -void test_pktio_default_cos(void)
> +void classification_test_pktio_default_cos(void)
>  {
> odp_packet_t pkt;
> odp_queue_t queue;
> @@ -344,7 +344,7 @@ void test_pktio_default_cos(void)
> odp_packet_free(pkt);
>  }
>
> -void configure_pktio_error_cos(void)
> +void classification_test_configure_pktio_error_cos(void)
>  {
> int retval;
> odp_queue_param_t qparam;
> @@ -380,7 +380,7 @@ void configure_pktio_error_cos(v

Re: [lng-odp] [PATCH 4/5] validation: cls: use correct MAC addresses

[Bala Manoharan]

The idea of having to create pktio in each and every test case is to
create robustness in test cases and have them as independent from each
other as possible. In classification when you remove a CoS rule it is
not expected to see the changes immediately some systems will have
latency and the packets might be classified using stale rules.
So it is better to destroy and re-create pktio interface for each test cases.

Regards,
Bala
Regards,
Bala


On 12 January 2016 at 23:41, Ivan Khoronzhuk  wrote:
> If pktion is in not promisc mode, a packet should contain correct
> MAC address.
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  .../classification/odp_classification_test_pmr.c   | 158 
> ++---
>  .../classification/odp_classification_tests.c  |  30 +++-
>  2 files changed, 96 insertions(+), 92 deletions(-)
>
> diff --git a/test/validation/classification/odp_classification_test_pmr.c 
> b/test/validation/classification/odp_classification_test_pmr.c
> index 0b3f279..bb69794 100644
> --- a/test/validation/classification/odp_classification_test_pmr.c
> +++ b/test/validation/classification/odp_classification_test_pmr.c
> @@ -13,22 +13,11 @@
>  #include 
>
>  static odp_pool_t pkt_pool;
> +static odp_pktio_t pktio_loop;
>
>  /** sequence number of IP packets */
>  odp_atomic_u32_t seq;
>
> -int classification_suite_pmr_init(void)
> -{
> -   pkt_pool = pool_create("classification_pmr_pool");
> -   if (ODP_POOL_INVALID == pkt_pool) {
> -   fprintf(stderr, "Packet pool creation failed.\n");
> -   return -1;
> -   }
> -
> -   odp_atomic_init_u32(&seq, 0);
> -   return 0;
> -}
> -
>  odp_pktio_t create_pktio(odp_queue_type_t q_type)
>  {
> odp_pktio_t pktio;
> @@ -55,6 +44,35 @@ odp_pktio_t create_pktio(odp_queue_type_t q_type)
> return pktio;
>  }
>
> +int classification_suite_pmr_init(void)
> +{
> +   pkt_pool = pool_create("classification_pmr_pool");
> +   if (ODP_POOL_INVALID == pkt_pool) {
> +   fprintf(stderr, "Packet pool creation failed.\n");
> +   return -1;
> +   }
> +
> +   pktio_loop = create_pktio(ODP_QUEUE_TYPE_SCHED);
> +
> +   odp_atomic_init_u32(&seq, 0);
> +   return 0;
> +}
> +
> +static odp_packet_t
> +cls_create_packet(bool vlan, odp_atomic_u32_t *seq, bool flag_udp)
> +{
> +   odp_packet_t pkt;
> +   odph_ethhdr_t *eth;
> +
> +   pkt = create_packet(pkt_pool, vlan, seq, flag_udp);
> +
> +   eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
> +   odp_pktio_mac_addr(pktio_loop, eth->src.addr, ODPH_ETHADDR_LEN);
> +   odp_pktio_mac_addr(pktio_loop, eth->dst.addr, ODPH_ETHADDR_LEN);
> +
> +   return pkt;
> +}
> +
>  void configure_default_cos(odp_pktio_t pktio, odp_cos_t *cos,
>odp_queue_t *queue, odp_pool_t *pool)
>  {
> @@ -93,6 +111,11 @@ int classification_suite_pmr_term(void)
>  {
> int retcode = 0;
>
> +   if (odp_pktio_close(pktio_loop)) {
> +   fprintf(stderr, "unable to close pktio_loop.\n");
> +   retcode = -1;
> +   }
> +
> if (0 != odp_pool_destroy(pkt_pool)) {
> fprintf(stderr, "pkt_pool destroy failed.\n");
> retcode = -1;
> @@ -109,7 +132,6 @@ void classification_test_pmr_term_tcp_dport(void)
> uint16_t val;
> uint16_t mask;
> int retval;
> -   odp_pktio_t pktio;
> odp_queue_t queue;
> odp_queue_t retqueue;
> odp_queue_t default_queue;
> @@ -128,10 +150,7 @@ void classification_test_pmr_term_tcp_dport(void)
> mask = 0x;
> seqno = 0;
>
> -   pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
> -   CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
> -
> -   configure_default_cos(pktio, &default_cos,
> +   configure_default_cos(pktio_loop, &default_cos,
>   &default_queue, &default_pool);
>
> match.term = ODP_PMR_TCP_DPORT;
> @@ -158,10 +177,10 @@ void classification_test_pmr_term_tcp_dport(void)
> cos = odp_cls_cos_create(cosname, &cls_param);
> CU_ASSERT(cos != ODP_COS_INVALID);
>
> -   retval = odp_pktio_pmr_cos(pmr, pktio, cos);
> +   retval = odp_pktio_pmr_cos(pmr, pktio_loop, cos);
> CU_ASSERT(retval == 0);
>
> -   pkt = create_packet(pkt_pool, false, &seq, false);
> +   pkt = cls_create_packet(false, &seq, false);
> CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
> seqno = cls_pkt_get_seq(pkt);
> CU_ASSERT(seqno != TEST_SEQ_INVALID);
> @@ -169,7 +188,7 @@ void classification_test_pmr_term_tcp_dport(void)
> tcp = (odph_tcphdr_t *)odp_packet_l4_ptr(pkt, NULL);
> tcp->dst_port = odp_cpu_to_be_16(CLS_DEFAULT_DPORT);
>
> -   enqueue_pktio_interface(pkt, pktio);
> +   enqueue_pktio_interface(pkt, pktio_loop);
>
> pkt = receive_packet(&retqueue, ODP_TIME_SEC_IN_NS);
> CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
> @@ -181,7 +

Re: [lng-odp] [PATCH 3/5] validation: cls: test_pmr: don't create default input queue

[Bala Manoharan]

The reason for default input queue is coz thats how linux generic
pktio works and as you said when running the same tests on HW the
default input queue will be ignored and the packet will be processed
correctly.

Regards,
Bala
Regards,
Bala


On 14 January 2016 at 13:15, Ivan Khoronzhuk  wrote:
>
> On 14.01.16 07:52, Bala Manoharan wrote:
>>
>> This patch does not apply maybe you need to rebase to HEAD.
>>
>> Regards,
>> Bala
>> Regards,
>> Bala
>>
> I will re-base, but this patch still has questions.
> Like, do we need to assign default input queue if it's not supposed to be
> used
> and completely replaced by default CoS? Also, seems I forgot to start pktio
> afterwards.
> But when I started it, I see that linux-generic implementation doesn't pass
> the test, strange.
> What is going on? My board passes it correctly.
>
>
>>
>> On 12 January 2016 at 23:41, Ivan Khoronzhuk 
>> wrote:
>>>
>>> There is no need to create default input queue for pktio if
>>> default CoS is assigned.
>>>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>>   .../classification/odp_classification_test_pmr.c   | 54
>>> --
>>>   1 file changed, 54 deletions(-)
>>>
>>> diff --git a/test/validation/classification/odp_classification_test_pmr.c
>>> b/test/validation/classification/odp_classification_test_pmr.c
>>> index 75d2a95..0b3f279 100644
>>> --- a/test/validation/classification/odp_classification_test_pmr.c
>>> +++ b/test/validation/classification/odp_classification_test_pmr.c
>>> @@ -55,39 +55,6 @@ odp_pktio_t create_pktio(odp_queue_type_t q_type)
>>>  return pktio;
>>>   }
>>>
>>> -int create_default_inq(odp_pktio_t pktio, odp_queue_type_t qtype)
>>> -{
>>> -   odp_queue_param_t qparam;
>>> -   odp_queue_t inq_def;
>>> -   char inq_name[ODP_QUEUE_NAME_LEN];
>>> -
>>> -   odp_queue_param_init(&qparam);
>>> -   qparam.sched.prio  = ODP_SCHED_PRIO_DEFAULT;
>>> -   qparam.sched.sync  = ODP_SCHED_SYNC_ATOMIC;
>>> -   qparam.sched.group = ODP_SCHED_GROUP_ALL;
>>> -
>>> -   snprintf(inq_name, sizeof(inq_name), "inq-pktio-%" PRIu64,
>>> -odp_pktio_to_u64(pktio));
>>> -   inq_def = odp_queue_lookup(inq_name);
>>> -   if (inq_def == ODP_QUEUE_INVALID)
>>> -   inq_def = odp_queue_create(
>>> -   inq_name,
>>> -   ODP_QUEUE_TYPE_PKTIN,
>>> -   qtype == ODP_QUEUE_TYPE_POLL ? NULL :
>>> &qparam);
>>> -
>>> -   CU_ASSERT_FATAL(inq_def != ODP_QUEUE_INVALID);
>>> -
>>> -   if (0 > odp_pktio_inq_setdef(pktio, inq_def))
>>> -   return -1;
>>> -
>>> -   if (odp_pktio_start(pktio)) {
>>> -   fprintf(stderr, "unable to start loop\n");
>>> -   return -1;
>>> -   }
>>> -
>>> -   return 0;
>>> -}
>>> -
>>>   void configure_default_cos(odp_pktio_t pktio, odp_cos_t *cos,
>>> odp_queue_t *queue, odp_pool_t *pool)
>>>   {
>>> @@ -163,8 +130,6 @@ void classification_test_pmr_term_tcp_dport(void)
>>>
>>>  pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
>>>  CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
>>> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
>>> -   CU_ASSERT(retval == 0);
>>>
>>>  configure_default_cos(pktio, &default_cos,
>>>&default_queue, &default_pool);
>>> @@ -237,7 +202,6 @@ void classification_test_pmr_term_tcp_dport(void)
>>>  odp_cos_destroy(cos);
>>>  odp_cos_destroy(default_cos);
>>>  odp_pmr_destroy(pmr);
>>> -   destroy_inq(pktio);
>>>  odp_queue_destroy(queue);
>>>  odp_queue_destroy(default_queue);
>>>  odp_pool_destroy(pool);
>>> @@ -273,8 +237,6 @@ void classification_test_pmr_term_tcp_sport(void)
>>>
>>>  pktio = create_pktio(ODP_QUEUE_TYPE_SCHED);
>>>  CU_ASSERT_FATAL(pktio != ODP_PKTIO_INVALID);
>>> -   retval = create_default_inq(pktio, ODP_QUEUE_TYPE_SCHED);
>>> -   CU_ASSERT(retval == 0);
>>>
>>>  configure_default_co

Re: [lng-odp] [PATCH 4/5] validation: cls: use correct MAC addresses

[Bala Manoharan]

In odp_classification_tests.c a common pktio_loop is used coz in that
suite the objective was to test the behaviour of a classification
system with all different possible configurations existing
concurrently. ie Configure L2 PMR, L3 PMR, default_cos, error_cos and
send an error packet and check that the packet reaches error CoS.

Yes tests can be sophisticated but as I pointed out earlier there are
few changes on the way for the classification API and it seems
reasonable to enhance the validation suite once the API changes are
completed.
Regards,
Bala


On 14 January 2016 at 13:09, Ivan Khoronzhuk  wrote:
>
>
> On 14.01.16 07:59, Bala Manoharan wrote:
>>
>> The idea of having to create pktio in each and every test case is to
>> create robustness in test cases and have them as independent from each
>> other as possible. In classification when you remove a CoS rule it is
>> not expected to see the changes immediately some systems will have
>> latency and the packets might be classified using stale rules.
>> So it is better to destroy and re-create pktio interface for each test
>> cases.
>>
>> Regards,
>> Bala
>> Regards,
>> Bala
>>
> Agree. Initially I've done like proposed, but then look in
> odp_classification_tests.c,
> and see that mostly common pktio_loop is used. I will correct to set MAC
> addresses
> for each test, but odp_classification_tests.c should be sophisticated also,
> later.
>
>
>>
>> On 12 January 2016 at 23:41, Ivan Khoronzhuk 
>> wrote:
>>>
>>> If pktion is in not promisc mode, a packet should contain correct
>>> MAC address.
>>>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>>   .../classification/odp_classification_test_pmr.c   | 158
>>> ++---
>>>   .../classification/odp_classification_tests.c  |  30 +++-
>>>   2 files changed, 96 insertions(+), 92 deletions(-)
>>>
>>> diff --git a/test/validation/classification/odp_classification_test_pmr.c
>>> b/test/validation/classification/odp_classification_test_pmr.c
>>> index 0b3f279..bb69794 100644
>>> --- a/test/validation/classification/odp_classification_test_pmr.c
>>> +++ b/test/validation/classification/odp_classification_test_pmr.c
>>> @@ -13,22 +13,11 @@
>>>   #include 
>>>
>>>   static odp_pool_t pkt_pool;
>>> +static odp_pktio_t pktio_loop;
>>>
>>>   /** sequence number of IP packets */
>>>   odp_atomic_u32_t seq;
>>>
>>> -int classification_suite_pmr_init(void)
>>> -{
>>> -   pkt_pool = pool_create("classification_pmr_pool");
>>> -   if (ODP_POOL_INVALID == pkt_pool) {
>>> -   fprintf(stderr, "Packet pool creation failed.\n");
>>> -   return -1;
>>> -   }
>>> -
>>> -   odp_atomic_init_u32(&seq, 0);
>>> -   return 0;
>>> -}
>>> -
>>>   odp_pktio_t create_pktio(odp_queue_type_t q_type)
>>>   {
>>>  odp_pktio_t pktio;
>>> @@ -55,6 +44,35 @@ odp_pktio_t create_pktio(odp_queue_type_t q_type)
>>>  return pktio;
>>>   }
>>>
>>> +int classification_suite_pmr_init(void)
>>> +{
>>> +   pkt_pool = pool_create("classification_pmr_pool");
>>> +   if (ODP_POOL_INVALID == pkt_pool) {
>>> +   fprintf(stderr, "Packet pool creation failed.\n");
>>> +   return -1;
>>> +   }
>>> +
>>> +   pktio_loop = create_pktio(ODP_QUEUE_TYPE_SCHED);
>>> +
>>> +   odp_atomic_init_u32(&seq, 0);
>>> +   return 0;
>>> +}
>>> +
>>> +static odp_packet_t
>>> +cls_create_packet(bool vlan, odp_atomic_u32_t *seq, bool flag_udp)
>>> +{
>>> +   odp_packet_t pkt;
>>> +   odph_ethhdr_t *eth;
>>> +
>>> +   pkt = create_packet(pkt_pool, vlan, seq, flag_udp);
>>> +
>>> +   eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
>>> +   odp_pktio_mac_addr(pktio_loop, eth->src.addr, ODPH_ETHADDR_LEN);
>>> +   odp_pktio_mac_addr(pktio_loop, eth->dst.addr, ODPH_ETHADDR_LEN);
>>> +
>>> +   return pkt;
>>> +}
>>> +
>>>   void configure_default_cos(odp_pktio_t pktio, odp_cos_t *cos,
>>> odp_queue_t *queue, odp_pool_t *pool)
>>>   {
>>> @@ -93,6 +111,11 @@ int classification_suite_pmr_term(void)
>>>  

Re: [lng-odp] [PATCH 5/5] validation: cls: split pmr chain test

[Bala Manoharan]

Agreed. Error CoS and L2 should be added as separate suites and I
would preferable add them in odp_classification_test_pmr.c so that
each are tested separately. Maybe rename the file also :)

As I pointed out enhancements can be done once API freeze is accepted.
Regards,
Bala


On 14 January 2016 at 13:26, Ivan Khoronzhuk  wrote:
>
>
> On 14.01.16 07:55, Bala Manoharan wrote:
>>
>> The idea behind this suite is to have a mechanism to test the
>> behaviour of the system after applying all the different PMR, default
>> CoS, error CoS and L2 and L3 CoS values. your suggested changes tests
>> each and every configuration individually which defeats the idea of
>> the suite.
>> There is a dedicated suite to test individual PMR values behaviour.
>>
>> Regards,
>> Bala
>
> Maybe, but it's hard to figure out what is broken, especially when some
> parts are not supported or implemented. In case of splitting it's possible
> to see what doesn't work, I can drop this patch but IMHO, one test includes
> a lot of different units that has not been tested before, like error CoS,
> default CoS (it was created but not tested), CoS with L2 pr...And now
> all in one chunk...one broken and seems like all are broken. It can be
> leaved like this but it should be tested separately.
>
>
>
>>
>>
>> On 12 January 2016 at 23:41, Ivan Khoronzhuk 
>> wrote:
>>>
>>> These tests are simple classification tests and better to see results
>>> for each of them separately.
>>>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>>   test/validation/classification/classification.h| 22 ---
>>>   .../classification/odp_classification_tests.c  | 72
>>> --
>>>   2 files changed, 38 insertions(+), 56 deletions(-)
>>>
>>> diff --git a/test/validation/classification/classification.h
>>> b/test/validation/classification/classification.h
>>> index f363812..6d2e55f 100644
>>> --- a/test/validation/classification/classification.h
>>> +++ b/test/validation/classification/classification.h
>>> @@ -13,7 +13,6 @@
>>>   #define SHM_PKT_BUF_SIZE1024
>>>
>>>   /* Config values for Default CoS */
>>> -#define TEST_DEFAULT   1
>>>   #defineCLS_DEFAULT 0
>>>   #define CLS_DEFAULT_SADDR  "10.0.0.1/32"
>>>   #define CLS_DEFAULT_DADDR  "10.0.0.100/32"
>>> @@ -21,29 +20,24 @@
>>>   #define CLS_DEFAULT_DPORT  2048
>>>
>>>   /* Config values for Error CoS */
>>> -#define TEST_ERROR 1
>>>   #define CLS_ERROR  1
>>>
>>>   /* Config values for PMR_CHAIN */
>>> -#define TEST_PMR_CHAIN 1
>>>   #define CLS_PMR_CHAIN_SRC  2
>>>   #define CLS_PMR_CHAIN_DST  3
>>>   #define CLS_PMR_CHAIN_SADDR"10.0.0.5/32"
>>>   #define CLS_PMR_CHAIN_PORT 3000
>>>
>>>   /* Config values for PMR */
>>> -#define TEST_PMR   1
>>>   #define CLS_PMR4
>>>   #define CLS_PMR_PORT   4000
>>>
>>>   /* Config values for PMR SET */
>>> -#define TEST_PMR_SET   1
>>>   #define CLS_PMR_SET5
>>>   #define CLS_PMR_SET_SADDR  "10.0.0.6/32"
>>>   #define CLS_PMR_SET_PORT   5000
>>>
>>>   /* Config values for CoS L2 Priority */
>>> -#define TEST_L2_QOS1
>>>   #define CLS_L2_QOS_0   6
>>>   #define CLS_L2_QOS_MAX 5
>>>
>>> @@ -68,8 +62,20 @@ void classification_test_pktio_set_skip(void);
>>>   void classification_test_pktio_set_headroom(void);
>>>   void classification_test_pmr_terms_avail(void);
>>>   void classification_test_pmr_terms_cap(void);
>>> -void classification_test_pktio_configure(void);
>>> -void classification_test_pktio_test(void);
>>> +
>>> +void classification_test_configure_pktio_default_cos(void);
>>> +void classification_test_configure_pktio_error_cos(void);
>>> +void classification_test_configure_cls_pmr_chain(void);
>>> +void classification_test_configure_cos_with_l2_priority(void);
>>> +void classification_test_configure_pmr_cos(void);
>>> +void classification_test_configure_pktio_pmr_match_set_cos(void);
>>> +
>>> +void classification_test_pktio_default_cos(void);
>>> +void classification_test_pktio_error_cos(void);
>>> +void classification_test_cls_pmr_chain(void);
&

Re: [lng-odp] [RFC PATCH] api: packet_io: return headroom when set new one

[Bala Manoharan]

Maximum headroom is defined in ODP_PACKET_MAX_HEADROOM and is an
implementation specific value and will not be greater than uint32/2.

Having said that the current definition of headroom in ODP is that it
will not exceed a single segment meaning the headroom will NOT
overflow by adding an empty segment before.

Regarding returning the previous allocated headroom, IMO it is a stale
value and is of no significance to the existing application. If you
have any use-case in mind for returning previous headroom pls share.

Regards,
Bala


On 13 January 2016 at 22:29, Ivan Khoronzhuk  wrote:
> It can be used to restore headroom later. Does it possible a headroom
> to be > sizeof(int32)/2?
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  include/odp/api/packet_io.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index cf92751..7b9d82a 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -356,12 +356,12 @@ int odp_pktio_skip_set(odp_pktio_t pktio, uint32_t 
> offset);
>   * Must not exceed the implementation
>   * defined ODP_PACKET_MAX_HEADROOM.
>   *
> - * @retval 0 on success
> + * @retval prevoius headroom
>   * @retval <0 on failure
>   *
>   * @note Optional.
>   */
> -int odp_pktio_headroom_set(odp_pktio_t pktio, uint32_t headroom);
> +int32_t  odp_pktio_headroom_set(odp_pktio_t pktio, int32_t headroom);
>
>  /**
>   * Get printable value for an odp_pktio_t
> --
> 1.9.1
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2 0/3] validation: cls: correct tests a little

[Bala Manoharan]

For the series:
Reviewed-by: Balasubramanian Manoharan 
Regards,
Bala


On 15 January 2016 at 22:58, Ivan Khoronzhuk  wrote:
> This patch series corrects classification tests to be a little bit
> adoptive.
>
> Since v1:
> - removed patch for deleting input queue, as it should be discussed first
> - removed patch for splitting, as new tests are supposed to be added
> - rebased on api-next to meet new requirements
> - assigned MAC address for every tests separately
>
> Ivan Khoronzhuk (3):
>   validation: cls: adopt for supported l3 PMR
>   validation: cls: assign default CoS before creating chain
>   validation: cls: use correct MAC addresses
>
>  test/validation/classification/classification.h|   6 +-
>  .../classification/odp_classification_basic.c  |   4 +-
>  .../classification/odp_classification_common.c |  52 ++
>  .../classification/odp_classification_test_pmr.c   | 108 
> +
>  .../classification/odp_classification_tests.c  |  25 ++---
>  .../classification/odp_classification_testsuites.h |   2 +
>  6 files changed, 156 insertions(+), 41 deletions(-)
>
> --
> 1.9.1
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] ODP IPSEC example application optimizations

[Bala Manoharan]

Hi Nikhil,

These changes are acceptable and please provide your patch to the list.

Also IMO we can keep it as configurable in the example so that if
someone wants to use AH for authentication he can use the existing
code.

Regards,
Bala


On 19 January 2016 at 17:17, Nikhil Agarwal  wrote:
> Hi All,
>
>
>
> Currently ODP IPSEC example application deploys ESP header for encryption
> and AH header for Authentication. This is not most widely use case scenario
> for IPSEC.  AH is known to have issue in NAT environment.
>
>
>
> Majority of deployment in IPSEC is being done with Encryption and
> Authentication under ESP Header only. I was trying to change the ODP example
> application to cater to this use case. If this is  acceptable to the
> community I can share the patch for the same. Please comment.
>
>
>
> Regards
>
> Nikhil
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] linux-generic: pktio: support multiple loop interfaces

[Bala Manoharan]

The "loop" as a keyword for loop interface was useful to test
validation suite since it needed only one interface but if we need
multiple loopback interface then I wouldn't suggest using "loopX"
keyword but a different mechanism to set an interface as loop.

I believe most platforms will be able to configure an existing
interface as loop so that it will send the packet back into the system
so if we need more than one loop interface it is better to get the
capability of the interface to check whether this particular interface
can support loopback and then set the interface as loop.
Regards,
Bala


On 19 January 2016 at 18:35, Maxim Uvarov  wrote:
> Bala, as I remember you also said that Cavium has several loop device. Looks
> like it's reasonable
> to update API then:
>
> API
>  * @note The device name "loop" is a reserved name for a loopback device
> used
>  * for testing purposes.
>
> Maxim.
>
>
> On 01/15/2016 18:46, Stuart Haslam wrote:
>>
>> The current implementation supports only a single loop interface named
>> "loop", but it's sometimes useful to use multiple loopback interfaces to
>> avoid the need to multiplex based on packet data.
>>
>> Allow interfaces named "loop" or "loopN" where supported numbers for N
>> are 0-254.
>>
>> Signed-off-by: Stuart Haslam 
>> ---
>>   .../linux-generic/include/odp_packet_io_internal.h |  1 +
>>   platform/linux-generic/pktio/loop.c| 40
>> +-
>>   2 files changed, 32 insertions(+), 9 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h
>> b/platform/linux-generic/include/odp_packet_io_internal.h
>> index 4d73952..1645670 100644
>> --- a/platform/linux-generic/include/odp_packet_io_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
>> @@ -45,6 +45,7 @@ struct pktio_if_ops;
>>   typedef struct {
>> odp_queue_t loopq;  /**< loopback queue for "loop"
>> device */
>> odp_bool_t promisc; /**< promiscuous mode state */
>> +   unsigned char if_mac[ETH_ALEN]; /**< MAC address for the interface
>> */
>>   } pkt_loop_t;
>> #ifdef HAVE_PCAP
>> diff --git a/platform/linux-generic/pktio/loop.c
>> b/platform/linux-generic/pktio/loop.c
>> index 95644c4..911eca8 100644
>> --- a/platform/linux-generic/pktio/loop.c
>> +++ b/platform/linux-generic/pktio/loop.c
>> @@ -19,27 +19,50 @@
>>   #include 
>>   #include 
>>   +#include 
>>   #include 
>>   -/* MAC address for the "loop" interface */
>> -static const char pktio_loop_mac[] = {0x02, 0xe9, 0x34, 0x80, 0x73,
>> 0x01};
>> +/* MAC address for the "loop" interface. When a numbered interface is
>> + * opened, the number suffix replaces the last digit of the MAC address,
>> + * e.g. loop1 has MAC 02:e9:34:80:73:01 */
>> +static const char pktio_loop_mac[] = {0x02, 0xe9, 0x34, 0x80, 0x73,
>> 0xff};
>> static int loopback_open(odp_pktio_t id, pktio_entry_t *pktio_entry,
>>  const char *devname, odp_pool_t pool ODP_UNUSED)
>>   {
>> -   if (strcmp(devname, "loop"))
>> +   char loopq_name[ODP_QUEUE_NAME_LEN];
>> +   int loop_num = -1;
>> +
>> +   if (strncmp(devname, "loop", 4))
>> return -1;
>>   - char loopq_name[ODP_QUEUE_NAME_LEN];
>> +   devname += strlen("loop");
>> +
>> +   /* valid names are loop[0-254] */
>> +   if (*devname != '\0') {
>> +   const char *p = devname;
>>   - snprintf(loopq_name, sizeof(loopq_name), "%" PRIu64
>> "-pktio_loopq",
>> -odp_pktio_to_u64(id));
>> +   while (*p != '\0')
>> +   if (!isdigit(*p++))
>> +   return -1;
>> +
>> +   loop_num = atoi(devname);
>> +   if (loop_num >= 0xff)
>> +   return -1;
>> +   }
>> +
>> +   snprintf(loopq_name, sizeof(loopq_name), "%" PRIu64
>> "-pktio_loop%s",
>> +odp_pktio_to_u64(id), devname);
>> pktio_entry->s.pkt_loop.loopq =
>> odp_queue_create(loopq_name, ODP_QUEUE_TYPE_POLL, NULL);
>> if (pktio_entry->s.pkt_loop.loopq == ODP_QUEUE_INVALID)
>> return -1;
>>   + memcpy(pktio_entry->s.pkt_loop.if_mac, pktio_loop_mac, ETH_ALEN);
>> +   if (loop_num != -1)
>> +   pktio_entry->s.pkt_loop.if_mac[ETH_ALEN-1] = loop_num;
>> +
>> return 0;
>>   }
>>   @@ -104,10 +127,9 @@ static int loopback_mtu_get(pktio_entry_t
>> *pktio_entry ODP_UNUSED)
>> return INT_MAX;
>>   }
>>   -static int loopback_mac_addr_get(pktio_entry_t *pktio_entry ODP_UNUSED,
>> -void *mac_addr)
>> +static int loopback_mac_addr_get(pktio_entry_t *pktio_entry, void
>> *mac_addr)
>>   {
>> -   memcpy(mac_addr, pktio_loop_mac, ETH_ALEN);
>> +   memcpy(mac_addr, pktio_entry->s.pkt_loop.if_mac, ETH_ALEN);
>> return ETH_ALEN;
>>   }
>>
>
>
___
lng-odp mailing list
lng-o

Re: [lng-odp] [PATCH 1/2] linux-generic: packet: hide frame_len behind accessor

[Bala Manoharan]

I was directly accessing this value to avoid a function call.
If required you can use the existing ODP API odp_packet_len() which
returns the total length.
Maybe you can move this as an inline function.

code snippet from odp_packet.c
===
uint32_t odp_packet_len(odp_packet_t pkt)
{
return odp_packet_hdr(pkt)->frame_len;
}

Regards,
Bala
Regards,
Bala


On 21 January 2016 at 13:51, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
>> Zoltan Kiss
>> Sent: Wednesday, January 20, 2016 6:37 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH 1/2] linux-generic: packet: hide frame_len
>> behind accessor
>>
>> The classification code accesses this variable directly, which prevents
>> reusing that code e.g. in ODP-DPDK.
>>
>> Signed-off-by: Zoltan Kiss 
>> ---
>>  platform/linux-generic/include/odp_classification_inlines.h | 5 +++--
>>  platform/linux-generic/include/odp_packet_internal.h| 5 +
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_classification_inlines.h
>> b/platform/linux-generic/include/odp_classification_inlines.h
>> index e9739aa..e4d87c9 100644
>> --- a/platform/linux-generic/include/odp_classification_inlines.h
>> +++ b/platform/linux-generic/include/odp_classification_inlines.h
>> @@ -24,6 +24,7 @@ extern "C" {
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* PMR term value verification function
>>  These functions verify the given PMR term value with the value in the
>> packet
>> @@ -33,7 +34,7 @@ These following functions return 1 on success and 0 on
>> failure
>>  static inline int verify_pmr_packet_len(odp_packet_hdr_t *pkt_hdr,
>>   pmr_term_value_t *term_value)
>>  {
>> - if (term_value->val == (pkt_hdr->frame_len &
>> + if (term_value->val == (packet_hdr_len(pkt_hdr) &
>>term_value->mask))
>>   return 1;
>>
>> @@ -240,7 +241,7 @@ static inline int verify_pmr_custom_frame(const
>> uint8_t *pkt_addr,
>>
>>   ODP_ASSERT(val_sz <= ODP_PMR_TERM_BYTES_MAX);
>>
>> - if (pkt_hdr->frame_len <= offset + val_sz)
>> + if (packet_hdr_len(pkt_hdr) <= offset + val_sz)
>>   return 0;
>>
>>   memcpy(&val, pkt_addr + offset, val_sz);
>> diff --git a/platform/linux-generic/include/odp_packet_internal.h
>> b/platform/linux-generic/include/odp_packet_internal.h
>> index 12e9cca..0b2e9d0 100644
>> --- a/platform/linux-generic/include/odp_packet_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_internal.h
>> @@ -214,6 +214,11 @@ static inline void pull_tail(odp_packet_hdr_t
>> *pkt_hdr, size_t len)
>>   pkt_hdr->frame_len -= len;
>>  }
>>
>> +static inline uint32_t packet_hdr_len(odp_packet_hdr_t* pkt_hdr)
>
> Since it's an accessor for frame length and not header length, better call it 
> packet_frame_len() or packet_len() (which matches packet_set_len() under).
>
> -Petri
>
>
>> +{
>> + return pkt_hdr->frame_len;
>> +}
>> +
>>  static inline void packet_set_len(odp_packet_t pkt, uint32_t len)
>>  {
>>   odp_packet_hdr(pkt)->frame_len = len;
>> --
>> 1.9.1
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/2 v2] linux-generic: packet: hide frame_len behind accessor

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

NIT: There is a minor check-patch error at the line
+static inline uint32_t packet_len(odp_packet_hdr_t* pkt_hdr)
Regards,
Bala


On 21 January 2016 at 20:59, Zoltan Kiss  wrote:
> The classification code accesses this variable directly, which prevents
> reusing that code e.g. in ODP-DPDK.
>
> Signed-off-by: Zoltan Kiss 
> ---
>
> v2: rename it packet_len(), to align with packet_set_len()
>
>
>  platform/linux-generic/include/odp_classification_inlines.h | 5 +++--
>  platform/linux-generic/include/odp_packet_internal.h| 5 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/platform/linux-generic/include/odp_classification_inlines.h 
> b/platform/linux-generic/include/odp_classification_inlines.h
> index e9739aa..5f0b564 100644
> --- a/platform/linux-generic/include/odp_classification_inlines.h
> +++ b/platform/linux-generic/include/odp_classification_inlines.h
> @@ -24,6 +24,7 @@ extern "C" {
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /* PMR term value verification function
>  These functions verify the given PMR term value with the value in the packet
> @@ -33,7 +34,7 @@ These following functions return 1 on success and 0 on 
> failure
>  static inline int verify_pmr_packet_len(odp_packet_hdr_t *pkt_hdr,
> pmr_term_value_t *term_value)
>  {
> -   if (term_value->val == (pkt_hdr->frame_len &
> +   if (term_value->val == (packet_len(pkt_hdr) &
>  term_value->mask))
> return 1;
>
> @@ -240,7 +241,7 @@ static inline int verify_pmr_custom_frame(const uint8_t 
> *pkt_addr,
>
> ODP_ASSERT(val_sz <= ODP_PMR_TERM_BYTES_MAX);
>
> -   if (pkt_hdr->frame_len <= offset + val_sz)
> +   if (packet_len(pkt_hdr) <= offset + val_sz)
> return 0;
>
> memcpy(&val, pkt_addr + offset, val_sz);
> diff --git a/platform/linux-generic/include/odp_packet_internal.h 
> b/platform/linux-generic/include/odp_packet_internal.h
> index 12e9cca..5078cc2 100644
> --- a/platform/linux-generic/include/odp_packet_internal.h
> +++ b/platform/linux-generic/include/odp_packet_internal.h
> @@ -214,6 +214,11 @@ static inline void pull_tail(odp_packet_hdr_t *pkt_hdr, 
> size_t len)
> pkt_hdr->frame_len -= len;
>  }
>
> +static inline uint32_t packet_len(odp_packet_hdr_t* pkt_hdr)
> +{
> +   return pkt_hdr->frame_len;
> +}
> +
>  static inline void packet_set_len(odp_packet_t pkt, uint32_t len)
>  {
> odp_packet_hdr(pkt)->frame_len = len;
> --
> 1.9.1
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/2] linux-generic: pool: catch duplicate free errors in debug builds

[Bala Manoharan]

Just curious does this issue not happen in production build?

Regards,
Bala


On 5 November 2015 at 23:32, Bill Fischofer  wrote:
> Signed-off-by: Bill Fischofer 
> ---
>  platform/linux-generic/odp_pool.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/platform/linux-generic/odp_pool.c 
> b/platform/linux-generic/odp_pool.c
> index 76a4aa5..9fd64d6 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -540,6 +540,8 @@ void odp_buffer_free(odp_buffer_t buf)
> odp_buffer_hdr_t *buf_hdr = odp_buf_to_hdr(buf);
> pool_entry_t *pool = odp_buf_to_pool(buf_hdr);
>
> +   ODP_ASSERT(buf_hdr->allocator != ODP_FREEBUF);
> +
> if (odp_unlikely(pool->s.low_wm_assert))
> ret_buf(&pool->s, buf_hdr);
> else
> --
> 2.1.4
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/2] linux-generic: pool: catch duplicate free errors in debug builds

[Bala Manoharan]

Just read the discussion in other thread. Seems reasonable

For the series:
Reviewed-by: Balasubramanian Manoharan 
Regards,
Bala


On 25 January 2016 at 10:56, Bala Manoharan  wrote:
> Just curious does this issue not happen in production build?
>
> Regards,
> Bala
>
>
> On 5 November 2015 at 23:32, Bill Fischofer  wrote:
>> Signed-off-by: Bill Fischofer 
>> ---
>>  platform/linux-generic/odp_pool.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/platform/linux-generic/odp_pool.c 
>> b/platform/linux-generic/odp_pool.c
>> index 76a4aa5..9fd64d6 100644
>> --- a/platform/linux-generic/odp_pool.c
>> +++ b/platform/linux-generic/odp_pool.c
>> @@ -540,6 +540,8 @@ void odp_buffer_free(odp_buffer_t buf)
>> odp_buffer_hdr_t *buf_hdr = odp_buf_to_hdr(buf);
>> pool_entry_t *pool = odp_buf_to_pool(buf_hdr);
>>
>> +   ODP_ASSERT(buf_hdr->allocator != ODP_FREEBUF);
>> +
>> if (odp_unlikely(pool->s.low_wm_assert))
>> ret_buf(&pool->s, buf_hdr);
>> else
>> --
>> 2.1.4
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

[Bala Manoharan]

Ping. Any feedback on the API definition and comments most welcome.

Regards,
Bala


On 26 January 2016 at 06:37, Bill Fischofer  wrote:
> The question of contexts for stateful classification was discussed last
> July.  We can discuss this further during tomorrow's public call to see if
> we want to pursue this for Monarch or if it should be considered a
> post-Monarch item.
>
> On Fri, Jan 22, 2016 at 9:47 AM, Ivan Khoronzhuk
>  wrote:
>>
>> + list
>>
>> On 22.01.16 17:46, Ivan Khoronzhuk wrote:
>>>
>>> It discussed several times when started to look at it and Bill proposed
>>> to add some cls environment.
>>> Finally, it's sent. After this change PMR is created while connection to
>>> CoSes,
>>> and it's eliminates ability to connect the same PMR to several CoSes
>>> (which may arise questions...),
>>> and maps PMR handle directly to physical rule. It greatly simplifies life
>>> for implementors.
>>>
>>>
>>>
>>> On 22.01.16 13:54, Balasubramanian Manoharan wrote:

 Packet match rule creation is modified to include source and destination
 class of service. Removes the ability to add any class of service
 directly
 with pktio. If a PMR needs to be applied at the pktio level the same
 should be applied to default class of service.

 Packet match rule destroy function is updated to removes the link
 between
 the source and destination class of service.

 Signed-off-by: Balasubramanian Manoharan 
 ---
   include/odp/api/classification.h | 74
 +---
   1 file changed, 24 insertions(+), 50 deletions(-)

 diff --git a/include/odp/api/classification.h
 b/include/odp/api/classification.h
 index f46912e..59bd01d 100644
 --- a/include/odp/api/classification.h
 +++ b/include/odp/api/classification.h
 @@ -50,7 +50,7 @@ extern "C" {
   /**
* @def ODP_PMR_INVAL
* Invalid odp_pmr_t value.
 - * This value is returned from odp_pmr_create()
 + * This value is returned from odp_cls_pmr_create()
* function on failure.
*/

 @@ -286,50 +286,33 @@ typedef struct odp_pmr_match_t {
   } odp_pmr_match_t;

   /**
 - * Create a packet match rule with mask and value
 + * Create a packet match rule between source and destination class of
 service.
 + * This packet matching rule is applied on all packets arriving at the
 source
 + * class of service and packets satisfying this PMR are sent to the
 destination
 + * class of service.
*
* @param[in]match   packet matching rule definition
 + * @param[in]src_cossource CoS handle
 + * @param[in]dst_cosdestination CoS handle
*
* @returnHandle of the matching rule
* @retvalODP_PMR_INVAL on failure
*/
 -odp_pmr_t odp_pmr_create(const odp_pmr_match_t *match);
 -
 +odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t *match, odp_cos_t
 src_cos,
 + odp_cos_t dst_cos);
   /**
 - * Invalidate a packet match rule and vacate its resources
 + * Function to destroy a packet match rule
 + * Destroying a PMR removes the link between the source and destination
 + * class of service and this PMR will no longer be applied for packets
 arriving
 + * at the source class of service. All the resource associated with the
 PMR
 + * be release but the class of service will remain intact.
*
* @param[in]pmr_idIdentifier of the PMR to be destroyed
*
* @retval0 on success
* @retval<0 on failure
*/
 -int odp_pmr_destroy(odp_pmr_t pmr_id);
 -
 -/**
 - * Apply a PMR to a pktio to assign a CoS.
 - *
 - * @param[in]pmr_idPMR to be activated
 - * @param[in]src_pktiopktio to which this PMR is to be applied
 - * @param[in]dst_cosCoS to be assigned by this PMR
 - *
 - * @retval0 on success
 - * @retval<0 on failure
 - */
 -int odp_pktio_pmr_cos(odp_pmr_t pmr_id,
 -  odp_pktio_t src_pktio, odp_cos_t dst_cos);
 -
 -/**
 - * Cascade a PMR to refine packets from one CoS to another.
 - *
 - * @param[in]pmr_idPMR to be activated
 - * @param[in]src_cosCoS to be filtered
 - * @param[in]dst_cosCoS to be assigned to packets filtered
 - *from src_cos that match pmr_id.
 - *
 - * @retval0 on success
 - * @retval<0 on failure
 - */
 -int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t src_cos, odp_cos_t
 dst_cos);
 +int odp_cls_pmr_destroy(odp_pmr_t pmr_id);

   /**
* Inquire about matching terms supported by the classifier
 @@ -357,19 +340,24 @@ unsigned odp_pmr_terms_avail(void);
* of value match rules, and the application shoul

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

[Bala Manoharan]

Okay. I will incorporate these changes in the next version.

Regards,
Bala


On 28 January 2016 at 20:31, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
> This is otherwise OK (and exactly the feature I was missing in the call 
> yesterday), but I'm wondering the benefit of having both odp_pmr_set_t and 
> odp_pmr_t types. API would be simpler with only one type.
>
> To me odp_pmr_t is a odp_pmr_set_t with only one matching rule in it, right? 
> We could get rid of odp_pmr_set_t (use only odp_pmr_t since it's a shorter 
> name) and define that a odp_pmr_t can be build from N cascaded match rules.
>
>
> odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t match[], unsigned num,
>  odp_cos_t src_cos, odp_cos_t dst_cos);
>
> Maximum 'num' value could be defined in a capability struct (a conservative 
> system could define 1), with potential other constrains on the tree 
> dimensions (max num pmr's per cos, etc).
>
>
> -Petri
>
>
>
>> -Original Message-
>> From: EXT Balasubramanian Manoharan [mailto:bala.manoha...@linaro.org]
>> Sent: Friday, January 22, 2016 1:54 PM
>> To: lng-odp@lists.linaro.org
>> Cc: Savolainen, Petri (Nokia - FI/Espoo); Balasubramanian Manoharan
>> Subject: [API-NEXT PATCHv1 1/4] api: classification: add pmr create api
>>
>> Packet match rule creation is modified to include source and destination
>> class of service. Removes the ability to add any class of service directly
>> with pktio. If a PMR needs to be applied at the pktio level the same
>> should be applied to default class of service.
>>
>> Packet match rule destroy function is updated to removes the link between
>> the source and destination class of service.
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  include/odp/api/classification.h | 74 +--
>> -
>>  1 file changed, 24 insertions(+), 50 deletions(-)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index f46912e..59bd01d 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -50,7 +50,7 @@ extern "C" {
>>  /**
>>   * @def ODP_PMR_INVAL
>>   * Invalid odp_pmr_t value.
>> - * This value is returned from odp_pmr_create()
>> + * This value is returned from odp_cls_pmr_create()
>>   * function on failure.
>>   */
>>
>> @@ -286,50 +286,33 @@ typedef struct odp_pmr_match_t {
>>  } odp_pmr_match_t;
>>
>>  /**
>> - * Create a packet match rule with mask and value
>> + * Create a packet match rule between source and destination class of
>> service.
>> + * This packet matching rule is applied on all packets arriving at the
>> source
>> + * class of service and packets satisfying this PMR are sent to the
>> destination
>> + * class of service.
>>   *
>>   * @param[in]match   packet matching rule definition
>> + * @param[in]src_cos source CoS handle
>> + * @param[in]dst_cos destination CoS handle
>>   *
>>   * @return   Handle of the matching rule
>>   * @retval   ODP_PMR_INVAL on failure
>>   */
>> -odp_pmr_t odp_pmr_create(const odp_pmr_match_t *match);
>> -
>> +odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t *match, odp_cos_t
>> src_cos,
>> +  odp_cos_t dst_cos);
>>  /**
>> - * Invalidate a packet match rule and vacate its resources
>> + * Function to destroy a packet match rule
>> + * Destroying a PMR removes the link between the source and destination
>> + * class of service and this PMR will no longer be applied for packets
>> arriving
>> + * at the source class of service. All the resource associated with the
>> PMR
>> + * be release but the class of service will remain intact.
>>   *
>>   * @param[in]pmr_id  Identifier of the PMR to be destroyed
>>   *
>>   * @retval   0 on success
>>   * @retval   <0 on failure
>>   */
>> -int odp_pmr_destroy(odp_pmr_t pmr_id);
>> -
>> -/**
>> - * Apply a PMR to a pktio to assign a CoS.
>> - *
>> - * @param[in]pmr_id  PMR to be activated
>> - * @param[in]src_pktio   pktio to which this PMR is to be 
>> applied
>> - * @param[in]dst_cos CoS to be assigned by this PMR
>> - *
>> - * @retval   0 on success
>> - * @retval   <0 on failure
>> - */
>> -int odp_pktio_pmr_cos(odp_pmr_t pmr_id,
>> -   odp_pktio_t src_pktio, odp_cos_t dst_cos);
>> -
>> -/**
>> - * Cascade a PMR to refine packets from one CoS to another.
>> - *
>> - * @param[in]pmr_id  PMR to be activated
>> - * @param[in]src_cos CoS to be filtered
>> - * @param[in]dst_cos CoS to be assigned to packets filtered
>> - *   from src_cos that match pmr_id.
>> - *
>> - * @retval   0 on success
>> - * @retval   <0 on failure
>> - */
>> -int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t src_cos, odp_cos_t
>> dst_cos);
>> +int odp_cls_pmr_destroy(odp_pmr_t pmr_id);
>>
>>  /**
>>   * Inqui

Re: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

[Bala Manoharan]

On 29 January 2016 at 15:40, Hongbo Zhang  wrote:
> On 29 January 2016 at 17:10, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
>>> hongbo.zh...@linaro.org
>>> Sent: Friday, January 29, 2016 10:50 AM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS
>>> ODP_CACHE_LINE_SIZE to its arch file
>>>
>>> From: Hongbo Zhang 
>>>
>>> Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
>>> held in one header file, they should be moved to their own arch file.
>>> This patch moves ODP_CACHE_LINE_SIZE for MIPS.
>>>
>>> Signed-off-by: Hongbo Zhang 
>>> ---
>>>  platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
>>>  platform/linux-generic/include/odp/align.h| 4 
>>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> index 3bfa0dc..3e4a1ed 100644
>>> --- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> +++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> @@ -11,6 +11,8 @@
>>>  extern "C" {
>>>  #endif
>>>
>>> +#define ODP_CACHE_LINE_SIZE 128
>>
>>
>> This is actually specific to octeon. MIPS spec allow extensions and Octeon 
>> does that. MIPS64 arch file could have MIPS defaults and then use #ifdef 
>> __OCTEON__ to override those which are Octeon specific. Maybe Cavium guys 
>> could help and check these arch definitions.
>>
> Then in the arch/mips64/odp/cpu_arch.h
>
> we do like this:
>
> #if defined __OCTEON__
> #define ODP_CACHE_LINE_SIZE 128
> #endif
>
> This should be OK?

Yes. This should be okay and if any other MIPS hw join in the future
they can add their #defines

Regards,
Bala

>
>>
>> -Petri
>>
>>
>>
>>> +
>>>  static inline void odp_cpu_pause(void)
>>>  {
>>>   __asm__ __volatile__ ("nop");
>>> diff --git a/platform/linux-generic/include/odp/align.h b/platform/linux-
>>> generic/include/odp/align.h
>>> index 4e045c6..6aba925 100644
>>> --- a/platform/linux-generic/include/odp/align.h
>>> +++ b/platform/linux-generic/include/odp/align.h
>>> @@ -35,10 +35,6 @@ extern "C" {
>>>
>>>  #define ODP_CACHE_LINE_SIZE 64
>>>
>>> -#elif defined __OCTEON__
>>> -
>>> -#define ODP_CACHE_LINE_SIZE 128
>>> -
>>>  #elif defined __powerpc__
>>>
>>>  #define ODP_CACHE_LINE_SIZE 64
>>> --
>>> 2.1.4
>>>
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv1 0/2] linux-generic:classification:add a new pmr term to support Range Match

[Bala Manoharan]

Packet matching rule to support the range was previously available in
ODP as part of pmr create function but the same was removed after
discussion since most of the existing HWs were not able to support the
range function.

We can add this point to the ODP public call to have a detailed
discussion on this topic.

Regards,
Bala
Regards,
Bala


On 1 February 2016 at 15:04, huanggaoyang  wrote:
> Range Match is a common case in packet classification process.
> The current pmr rules only support exact value. Simply, if we create a pmr 
> with term ODP_PMR_TCP_SPORT and value 2048,
> then only the packets from src-port:2048 will match it, while those from 2047 
> or 2049 won't match.
> In this patch, I added a new pmr term to support user defined Range Match 
> rule.
> That means, user can create the rule with the min and max value of the 
> key(which is determined by offset+mask+val_size),
> then packets with a key that satisfiy min<=key<=max will all match the rule.
>
> huanggaoyang (2):
>   linux-generic:classification: add a new pmr term to support range
> match
>   linux-generic:classification:add test case for the pmr term
> ODP_PMR_CUSTOM_RANGE
>
>  include/odp/api/classification.h   |  16 ++-
>  .../include/odp_classification_datamodel.h |  16 ++-
>  .../include/odp_classification_inlines.h   |  37 +-
>  platform/linux-generic/odp_classification.c|  23 +++-
>  test/validation/classification/classification.h|   1 +
>  .../classification/odp_classification_test_pmr.c   | 135 
> -
>  6 files changed, 214 insertions(+), 14 deletions(-)
>
> --
> 1.9.1
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv2 1/4] api: classification: add pmr create api

[Bala Manoharan]

Regards,
Bala


On 2 February 2016 at 14:53, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: EXT Balasubramanian Manoharan [mailto:bala.manoha...@linaro.org]
>> Sent: Monday, February 01, 2016 2:56 PM
>> To: lng-odp@lists.linaro.org
>> Cc: Savolainen, Petri (Nokia - FI/Espoo); Balasubramanian Manoharan
>> Subject: [API-NEXT PATCHv2 1/4] api: classification: add pmr create api
>>
>> Packet match rule creation is modified to include source and destination
>> class of service. Removes the ability to add any class of service directly
>> with pktio. If a PMR needs to be applied at the pktio level the same
>> should be applied to default class of service.
>>
>> Packet match rule destroy function is updated to removes the link between
>> the source and destination class of service.
>>
>> odp_pmr_match_set_t handle is removed and pmr create function is modified
>> to take number of terms and composite rule is created by providing more
>> than one term.
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> v2: removes pmr match set
>>
>>  include/odp/api/classification.h | 142 ++
>> -
>>  1 file changed, 35 insertions(+), 107 deletions(-)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index f46912e..263ea7c 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -50,16 +50,11 @@ extern "C" {
>>  /**
>>   * @def ODP_PMR_INVAL
>>   * Invalid odp_pmr_t value.
>> - * This value is returned from odp_pmr_create()
>> + * This value is returned from odp_cls_pmr_create()
>>   * function on failure.
>>   */
>>
>>  /**
>> - * @def ODP_PMR_SET_INVAL
>> - * Invalid odp_pmr_set_t value.
>> - */
>> -
>> -/**
>>   * class of service packet drop policies
>>   */
>>  typedef enum {
>> @@ -286,50 +281,54 @@ typedef struct odp_pmr_match_t {
>>  } odp_pmr_match_t;
>>
>>  /**
>> - * Create a packet match rule with mask and value
>> + * Create a packet match rule between source and destination class of
>> service.
>> + * This packet matching rule is applied on all packets arriving at the
>> source
>> + * class of service and packets satisfying this PMR are sent to the
>> destination
>> + * class of service.
>> + * A composite PMR rule is created when the number of terms in the match
>> rule
>> + * is more than one. The composite rule is considered as matching only if
>> + * the packet satisfies all the terms in Packet Match Rule.
>> + * The underlying platform may not support all or any specific
>> combination
>> + * of value match rules, and the application should take care
>> + * of inspecting the return value when installing such rules, and perform
>> + * appropriate fallback action.
>>   *
>> - * @param[in]match   packet matching rule definition
>> + * @param[in]num_terms   Number of terms in the match rule.
>> + * @param[in]terms   Array of odp_pmr_match_t entries, one 
>> entry
>> per
>> + *   term desired.
>> + * @param[in]src_cos source CoS handle
>> + * @param[in]dst_cos destination CoS handle
>>   *
>> - * @return   Handle of the matching rule
>> - * @retval   ODP_PMR_INVAL on failure
>> + * @retval   Hanlde to the Packet Match Rule.
>
> Typo  ^^
>
> Use @return instead of @retval, when the value is not predefined (a valid 
> handle).

Okay.
>
>
>> + * @retval   ODP_PMR_INVAL on failure
>>   */
>> -odp_pmr_t odp_pmr_create(const odp_pmr_match_t *match);
>> +odp_pmr_t odp_cls_pmr_create(int num_terms, const odp_pmr_match_t *terms,
>> +  odp_cos_t src_cos, odp_cos_t dst_cos);
>
>
> To match similar function prototypes in other APIs (e.g. xxx_multi()):
> - first the table as an array
> - then number of elements in the array
>
> odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t terms[], int num_terms, 
> odp_cos_t src_cos, odp_cos_t dst_cos);
>
>
> For example, it's easier to understand what "1" (or num) stands for when 
> defined like this ...
>
> odp_cls_pmr_create(terms, 1, src_cos, dst_cos);
>
> ... instead of this.
>
> odp_cls_pmr_create(1, terms, src_cos, dst_cos);

Agreed.
>
>
>
>
>
>>
>>  /**
>> - * Invalidate a packet match rule and vacate its resources
>> + * Function to destroy a packet match rule
>> + * Destroying a PMR removes the link between the source and destination
>> + * class of service and this PMR will no longer be applied for packets
>> arriving
>> + * at the source class of service. All the resource associated with the
>> PMR
>> + * be release but the class of service will remain intact.
>> + * Depending on the implementation details, destroying a composite rule
>> + * may not guarantee the availability of hardware resources to create the
>> + * same or essentially similar rule.
>>   *
>>   * @param[in]pmr_id  Identifier of the PMR to be destroyed

Re: [lng-odp] [API-NEXT PATCHv3 3/4] validation: classification: adds validation suite for pmr create api

[Bala Manoharan]

Thanks Bill.
Looks like the latest merge in api-next has created conflict in my patch.
I will rebase to HEAD and post V4.

Regards,
Bala


On 3 February 2016 at 21:37, Bill Fischofer  wrote:
> Part 3 of this patch fails to apply to the head of api-next for me:
>
> bill@Ubuntu15:~/linaro/balapmr$ git am --reject ~/Mail/Incoming/Bala/7
> Applying: validation: classification: adds validation suite for pmr create
> api
> Checking patch test/validation/classification/classification.h...
> Checking patch test/validation/classification/odp_classification_basic.c...
> Checking patch test/validation/classification/odp_classification_common.c...
> Checking patch
> test/validation/classification/odp_classification_test_pmr.c...
> error: while searching for:
> return 0;
> }
>
> odp_pktio_t create_pktio(odp_queue_type_t q_type)
> {
> odp_pktio_t pktio;
> odp_pktio_param_t pktio_param;
> int ret;
>
> if (pkt_pool == ODP_POOL_INVALID)
> return ODP_PKTIO_INVALID;
>
> odp_pktio_param_init(&pktio_param);
> if (q_type == ODP_QUEUE_TYPE_POLL)
> pktio_param.in_mode = ODP_PKTIN_MODE_POLL;
> else
> pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
>
> pktio = odp_pktio_open("loop", pkt_pool, &pktio_param);
> if (pktio == ODP_PKTIO_INVALID) {
> ret = odp_pool_destroy(pkt_pool);
> if (ret)
> fprintf(stderr, "unable to destroy pool.\n");
> return ODP_PKTIO_INVALID;
> }
>
> return pktio;
> }
>
> int create_default_inq(odp_pktio_t pktio, odp_queue_type_t qtype)
> {
> odp_queue_param_t qparam;
>
> error: patch failed:
> test/validation/classification/odp_classification_test_pmr.c:29
> Hunk #2 succeeded at 161 (offset 25 lines).
> Hunk #3 succeeded at 169 (offset 25 lines).
> Hunk #4 succeeded at 184 (offset 25 lines).
> Hunk #5 succeeded at 238 (offset 25 lines).
> Hunk #6 succeeded at 274 (offset 25 lines).
> Hunk #7 succeeded at 282 (offset 25 lines).
> Hunk #8 succeeded at 297 (offset 25 lines).
> Hunk #9 succeeded at 349 (offset 25 lines).
> Hunk #10 succeeded at 385 (offset 25 lines).
> Hunk #11 succeeded at 393 (offset 25 lines).
> Hunk #12 succeeded at 408 (offset 25 lines).
> Hunk #13 succeeded at 461 (offset 25 lines).
> Hunk #14 succeeded at 497 (offset 25 lines).
> Hunk #15 succeeded at 505 (offset 25 lines).
> Hunk #16 succeeded at 520 (offset 25 lines).
> Hunk #17 succeeded at 572 (offset 25 lines).
> Hunk #18 succeeded at 607 (offset 25 lines).
> Hunk #19 succeeded at 615 (offset 25 lines).
> Hunk #20 succeeded at 630 (offset 25 lines).
> Hunk #21 succeeded at 676 (offset 25 lines).
> Hunk #22 succeeded at 712 (offset 25 lines).
> Hunk #23 succeeded at 720 (offset 25 lines).
> Hunk #24 succeeded at 735 (offset 25 lines).
> Hunk #25 succeeded at 777 (offset 25 lines).
> Hunk #26 succeeded at 814 (offset 25 lines).
> Hunk #27 succeeded at 822 (offset 25 lines).
> Hunk #28 succeeded at 837 (offset 25 lines).
> Hunk #29 succeeded at 884 (offset 25 lines).
> Hunk #30 succeeded at 921 (offset 25 lines).
> Hunk #31 succeeded at 929 (offset 25 lines).
> Hunk #32 succeeded at 951 (offset 25 lines).
> Hunk #33 succeeded at 979 (offset 25 lines).
> Hunk #34 succeeded at 1016 (offset 25 lines).
> Hunk #35 succeeded at 1024 (offset 25 lines).
> Hunk #36 succeeded at 1046 (offset 25 lines).
> Hunk #37 succeeded at 1074 (offset 25 lines).
> Hunk #38 succeeded at 1107 (offset 25 lines).
> Hunk #39 succeeded at 1129 (offset 25 lines).
> Hunk #40 succeeded at 1176 (offset 25 lines).
> Checking patch test/validation/classification/odp_classification_tests.c...
> Hunk #4 succeeded at 189 (offset -2 lines).
> Hunk #5 succeeded at 200 (offset -2 lines).
> Hunk #6 succeeded at 494 (offset -3 lines).
> error: while searching for:
> char queuename[ODP_QUEUE_NAME_LEN];
> char poolname[ODP_POOL_NAME_LEN];
>
> val = CLS_PMR_PORT;
> mask = 0x;
> match.term = find_first_supported_l3_pmr();
> match.val = &val;
> match.mask = &mask;
> match.val_sz = sizeof(val);
>
> pmr_list[CLS_PMR] = odp_pmr_create(&match);
> CU_ASSERT_FATAL(pmr_list[CLS_PMR] != ODP_PMR_INVAL);
>
> odp_queue_param_init(&qparam);
> qparam.sched.prio = ODP_SCHED_PRIO_HIGHEST;
> qparam.sched.sync = ODP_SCHED_SYNC_NONE;
>
> error: patch failed:
> test/validation/classification/odp_classification_tests.c:512
> Hunk #8 succeeded at 533 (offset 6 lines).
> Hunk #9 succeeded at 567 (offset 6 lines).
> error: while searching for:
> uint32_t addr = 0;
> uint32_t mask;
>
> parse_ipv4_string(CLS_PMR_SET_SADDR, &addr, &mask);
> pmr_terms[0].term = ODP_PMR_SIP_ADDR;
> pmr_terms[0].val = &addr;
> pmr_terms[0].mask = &mask;
> pmr_terms[0].val_sz = sizeof(addr);
>
>
> val = CLS_PMR_SET_PORT;
> maskport = 0x;
> pmr_terms[1].term = find_first_supported_l3_pmr();
> pmr_terms[1].val = &val;
> pmr_terms[1].mask = &maskport;
> pmr_terms[1].val_sz = sizeof(val);
>
> retval = odp_pmr_match_set_create(num_terms, pmr_terms, &pmr_set);
> CU_ASSERT(retval > 0);
>
> odp_queue_param_init(&qparam);
> qparam.sched.prio = ODP_SCHED_PRIO_HIGHEST;
> qparam.sched.sync = ODP_SCHED_SYNC_NONE;
>
> error: patch failed:
> 

Re: [lng-odp] [API-NEXT PATCHv4 0/4] add PMR create API

[Bala Manoharan]

My mistake. I am sending v5 shortly.

Regards,
Bala


On 3 February 2016 at 22:51, Bill Fischofer  wrote:
> This now applies and runs, however there are doxygen issues:
>
> bill@Ubuntu15:~/linaro/balapmr$ make doxygen-html
> rm -rf doc/output
> make --directory=./doc/images
> make[1]: Entering directory '/home/bill/linaro/balapmr/doc/images'
> mscgen -T svg -i resource_management.msc -o resource_management.svg
> make[1]: Leaving directory '/home/bill/linaro/balapmr/doc/images'
> SRCDIR='.' PROJECT='OpenDataPlane' DOCDIR='doc/output'
> VERSION='1.6.0.0.git412.g6b638d0' WITH_PLATFORM='linux-generic'
> PERL_PATH='/usr/bin/perl' HAVE_DOT='NO' GENERATE_MAN='NO' GENERATE_RTF='NO'
> GENERATE_XML='NO' GENERATE_HTMLHELP='NO' GENERATE_CHI='NO'
> GENERATE_HTML='YES' GENERATE_LATEX='YES' /usr/bin/doxygen
> ./doc/application-api-guide/doxygen.cfg
> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:38:
> warning: Member ODP_PMR_SET_INVAL (macro definition) of group
> odp_classification is not documented.
> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:37:
> warning: Member odp_pmr_set_t (typedef) of group odp_classification is not
> documented.
> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:38:
> warning: Member ODP_PMR_SET_INVAL (macro definition) of group
> odp_classification is not documented.
> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:37:
> warning: Member odp_pmr_set_t (typedef) of group odp_classification is not
> documented.
>
>
> On Wed, Feb 3, 2016 at 11:15 AM, Balasubramanian Manoharan
>  wrote:
>>
>> Packet match rule creation is modified to include source and destination
>> class of service. Removes the ability to add any class of service directly
>> with pktio. If a PMR needs to be applied at the pktio level the same
>> should be applied to default class of service.
>>
>> Packet match rule destroy function is updated to removes the link between
>> the source and destination class of service.
>>
>> odp_pmr_match_set_t handle is removed and pmr create function is modified
>> to take number of terms and composite rule is created by providing more
>> than one term.
>>
>> Since this patch changes the API, the entire set has to be merged before
>> applying to prevent compilation error in the middle.
>>
>> v4: Rebase to HEAD
>>
>> v3: Incorporates Review comments from Petri
>>  - API reviewed-by from Petri
>>
>> v2: Removes pmr match set
>>- Modifies pmr create function to create composite pmr rules
>>
>> v1: Initial version for pmr create api change
>>- Introduces pmr create api and linux-generic changes
>>
>> Balasubramanian Manoharan (4):
>>   api: classification: add pmr create api
>>   linux-generic: classification: implement pmr create api
>>   validation: classification: adds validation suite for pmr create api
>>   example: classifier: modifications for pmr create api
>>
>>  example/classifier/odp_classifier.c|  38 +--
>>  include/odp/api/classification.h   | 140 ++---
>>  .../include/odp_classification_datamodel.h |  48 +---
>>  .../include/odp_classification_internal.h  |  21 +-
>>  platform/linux-generic/odp_classification.c| 314
>> +
>>  platform/linux-generic/odp_packet_io.c |  24 +-
>>  test/validation/classification/classification.h|   1 -
>>  .../classification/odp_classification_basic.c  | 141 +
>>  .../classification/odp_classification_common.c |  26 ++
>>  .../classification/odp_classification_test_pmr.c   | 240 ++--
>>  .../classification/odp_classification_tests.c  |  87 +++---
>>  .../classification/odp_classification_testsuites.h |   4 +-
>>  12 files changed, 388 insertions(+), 696 deletions(-)
>>
>> --
>> 1.9.1
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv4 0/4] add PMR create API

[Bala Manoharan]

New version sent.
Thanks for such quick reviews Bill. :)

Regards,
Bala


On 3 February 2016 at 23:12, Bala Manoharan  wrote:
> My mistake. I am sending v5 shortly.
>
> Regards,
> Bala
>
>
> On 3 February 2016 at 22:51, Bill Fischofer  wrote:
>> This now applies and runs, however there are doxygen issues:
>>
>> bill@Ubuntu15:~/linaro/balapmr$ make doxygen-html
>> rm -rf doc/output
>> make --directory=./doc/images
>> make[1]: Entering directory '/home/bill/linaro/balapmr/doc/images'
>> mscgen -T svg -i resource_management.msc -o resource_management.svg
>> make[1]: Leaving directory '/home/bill/linaro/balapmr/doc/images'
>> SRCDIR='.' PROJECT='OpenDataPlane' DOCDIR='doc/output'
>> VERSION='1.6.0.0.git412.g6b638d0' WITH_PLATFORM='linux-generic'
>> PERL_PATH='/usr/bin/perl' HAVE_DOT='NO' GENERATE_MAN='NO' GENERATE_RTF='NO'
>> GENERATE_XML='NO' GENERATE_HTMLHELP='NO' GENERATE_CHI='NO'
>> GENERATE_HTML='YES' GENERATE_LATEX='YES' /usr/bin/doxygen
>> ./doc/application-api-guide/doxygen.cfg
>> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:38:
>> warning: Member ODP_PMR_SET_INVAL (macro definition) of group
>> odp_classification is not documented.
>> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:37:
>> warning: Member odp_pmr_set_t (typedef) of group odp_classification is not
>> documented.
>> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:38:
>> warning: Member ODP_PMR_SET_INVAL (macro definition) of group
>> odp_classification is not documented.
>> /home/bill/linaro/balapmr/platform/linux-generic/include/odp/plat/classification_types.h:37:
>> warning: Member odp_pmr_set_t (typedef) of group odp_classification is not
>> documented.
>>
>>
>> On Wed, Feb 3, 2016 at 11:15 AM, Balasubramanian Manoharan
>>  wrote:
>>>
>>> Packet match rule creation is modified to include source and destination
>>> class of service. Removes the ability to add any class of service directly
>>> with pktio. If a PMR needs to be applied at the pktio level the same
>>> should be applied to default class of service.
>>>
>>> Packet match rule destroy function is updated to removes the link between
>>> the source and destination class of service.
>>>
>>> odp_pmr_match_set_t handle is removed and pmr create function is modified
>>> to take number of terms and composite rule is created by providing more
>>> than one term.
>>>
>>> Since this patch changes the API, the entire set has to be merged before
>>> applying to prevent compilation error in the middle.
>>>
>>> v4: Rebase to HEAD
>>>
>>> v3: Incorporates Review comments from Petri
>>>  - API reviewed-by from Petri
>>>
>>> v2: Removes pmr match set
>>>- Modifies pmr create function to create composite pmr rules
>>>
>>> v1: Initial version for pmr create api change
>>>- Introduces pmr create api and linux-generic changes
>>>
>>> Balasubramanian Manoharan (4):
>>>   api: classification: add pmr create api
>>>   linux-generic: classification: implement pmr create api
>>>   validation: classification: adds validation suite for pmr create api
>>>   example: classifier: modifications for pmr create api
>>>
>>>  example/classifier/odp_classifier.c|  38 +--
>>>  include/odp/api/classification.h   | 140 ++---
>>>  .../include/odp_classification_datamodel.h |  48 +---
>>>  .../include/odp_classification_internal.h  |  21 +-
>>>  platform/linux-generic/odp_classification.c| 314
>>> +
>>>  platform/linux-generic/odp_packet_io.c |  24 +-
>>>  test/validation/classification/classification.h|   1 -
>>>  .../classification/odp_classification_basic.c  | 141 +
>>>  .../classification/odp_classification_common.c |  26 ++
>>>  .../classification/odp_classification_test_pmr.c   | 240 ++--
>>>  .../classification/odp_classification_tests.c  |  87 +++---
>>>  .../classification/odp_classification_testsuites.h |   4 +-
>>>  12 files changed, 388 insertions(+), 696 deletions(-)
>>>
>>> --
>>> 1.9.1
>>>
>>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 2/4] helper: ip: added ipv4 address parse

[Bala Manoharan]

IMO, it is better to add feature for parsing the subnet mask for ipv4
address in the same function. We can add the string format in CIDR notation
as "xxx.xxx.xxx.xxx/yy" where yy is subnet prefix. The mask will be filled
as a uint32_t same as in ipv4 address.

syntax will be something like odph_ipv4_addr_parse(uint32_t *ip_addr,
uint32_t *mask, const char *str)

Regards,
Bala

On 9 February 2016 at 17:55, Petri Savolainen 
wrote:

> IPv4 address parse function is commonly needed by
> test applications. A common parse function harmonizes the
> definition IPv4 address as a command line parameter.
>
> Signed-off-by: Petri Savolainen 
> ---
>  helper/Makefile.am |   1 +
>  helper/include/odp/helper/ip.h |  22 +-
>  helper/ip.c|  30 
>  helper/test/odp_parse.c| 153
> +
>  4 files changed, 203 insertions(+), 3 deletions(-)
>  create mode 100644 helper/ip.c
>
> diff --git a/helper/Makefile.am b/helper/Makefile.am
> index 22147fa..377a7b9 100644
> --- a/helper/Makefile.am
> +++ b/helper/Makefile.am
> @@ -30,6 +30,7 @@ noinst_HEADERS = \
>
>  __LIB__libodphelper_la_SOURCES = \
> eth.c \
> +   ip.c \
> linux.c \
> ring.c \
> hashtable.c \
> diff --git a/helper/include/odp/helper/ip.h
> b/helper/include/odp/helper/ip.h
> index 2fa4aae..769384f 100644
> --- a/helper/include/odp/helper/ip.h
> +++ b/helper/include/odp/helper/ip.h
> @@ -18,9 +18,7 @@
>  extern "C" {
>  #endif
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
>
>  #include 
> @@ -32,6 +30,7 @@ extern "C" {
>  #define ODPH_IPV4 4  /**< IP version 4 */
>  #define ODPH_IPV4HDR_LEN 20  /**< Min length of IP header (no
> options) */
>  #define ODPH_IPV4HDR_IHL_MIN  5  /**< Minimum IHL value*/
> +#define ODPH_IPV4ADDR_LEN 4  /**< IPv4 address length in bytes */
>
>  /** @internal Returns IPv4 version */
>  #define ODPH_IPV4HDR_VER(ver_ihl) (((ver_ihl) & 0xf0) >> 4)
> @@ -176,6 +175,23 @@ typedef struct ODP_PACKED {
>  /**@}*/
>
>  /**
> + * Parse IPv4 address from a string
> + *
> + * Parses IPv4 address from the string which must be passed in the format
> of
> + * four decimal digits delimited by dots (xxx.xxx.xxx.xxx). All four
> digits
> + * have to be present and may have leading zeros. String does not have to
> be
> + * NULL terminated. The address is written only when successful. The
> address
> + * byte order is CPU native.
> + *
> + * @param[out] ip_addrPointer to IPv4 address for output (in native
> endian)
> + * @param  strIPv4 address string to be parsed
> + *
> + * @retval 0  on success
> + * @retval <0 on failure
> + */
> +int odph_ipv4_addr_parse(uint32_t *ip_addr, const char *str);
> +
> +/**
>   * @}
>   */
>  #ifdef __cplusplus
> diff --git a/helper/ip.c b/helper/ip.c
> new file mode 100644
> index 000..eb73e5a
> --- /dev/null
> +++ b/helper/ip.c
> @@ -0,0 +1,30 @@
> +/* Copyright (c) 2016, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +int odph_ipv4_addr_parse(uint32_t *ip_addr, const char *str)
> +{
> +   unsigned byte[ODPH_IPV4ADDR_LEN];
> +   int i;
> +
> +   memset(byte, 0, sizeof(byte));
> +
> +   if (sscanf(str, "%u.%u.%u.%u",
> +  &byte[0], &byte[1], &byte[2], &byte[3]) !=
> ODPH_IPV4ADDR_LEN)
> +   return -1;
> +
> +   for (i = 0; i < ODPH_IPV4ADDR_LEN; i++)
> +   if (byte[i] > 255)
> +   return -1;
> +
> +   *ip_addr = byte[0] << 24 | byte[1] << 16 | byte[2] << 8 | byte[3];
> +
> +   return 0;
> +}
> diff --git a/helper/test/odp_parse.c b/helper/test/odp_parse.c
> index f20b909..77c506b 100644
> --- a/helper/test/odp_parse.c
> +++ b/helper/test/odp_parse.c
> @@ -8,6 +8,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -22,6 +23,11 @@ static int different_mac(odph_ethaddr_t *mac1,
> odph_ethaddr_t *mac2)
>mac1->addr[5] != mac2->addr[5];
>  }
>
> +static int different_ipv4(uint32_t *ip_addr1, uint32_t *ip_addr2)
> +{
> +   return *ip_addr1 != *ip_addr2;
> +}
> +
>  static int test_mac(void)
>  {
> odph_ethaddr_t mac;
> @@ -195,11 +201,158 @@ static int test_mac(void)
> return 0;
>  }
>
> +static int test_ipv4(void)
> +{
> +   uint32_t ip_addr;
> +   uint32_t ref;
> +
> +   ip_addr = 0;
> +   ref = 0;
> +
> +   /*
> +* Erroneous strings
> +*/
> +
> +   /* String must not start with other chars */
> +   if (!odph_ipv4_addr_parse(&ip_addr, "foo 1.2.3.4")) {
> +   LOG_ERR("Accepted bad string\n");
> +   return -1;
> +   }
> +
> +   /* Missing digit */
> +   if (

Re: [lng-odp] [API-NEXT PATCH 2/4] helper: ip: added ipv4 address parse

[Bala Manoharan]

On 10 February 2016 at 15:36, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Yes, subnet support is needed and I left it for future development. This
> ipv4_addr function is for single IP address input (set local or dest
> address, etc). It would be waste to require a (/32) subnet masks for a
> single IP address. Also, the same functions would be needed for IPv6.
>

I was thinking that if only ipv4 address parsing was required we could
simply ignore the subnet prefix so that if the input string has only
"xxx.xxx.xxx.xxx" the function returns only ipv4 address and NULL for mask.

The reason for suggesting to include mask parsing is that the examples in
odp both ipsec and classifier require mask and it would be useful if we
could reuse the same helper for both.

Regards,
Bala


>
>
> The subnet function could return either the number of prefix bits …
>
>
>
> // String format xxx.xxx.xxx.xxx/yy
>
> int odph_ipv4_subnet_parse(uint32_t *ip_addr, unsigned *prefix_bits, const
> char *str);
>
>
>
> … the mask.
>
>
>
> int odph_ipv4_subnet_parse(uint32_t *ip_addr, uint32_t *subnet_mask, const
> char *str);
>
>
>
>
>
> -Petri
>
>
>
>
>
>
>
> *From:* EXT Bala Manoharan [mailto:bala.manoha...@linaro.org]
> *Sent:* Wednesday, February 10, 2016 6:40 AM
> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 2/4] helper: ip: added ipv4
> address parse
>
>
>
> IMO, it is better to add feature for parsing the subnet mask for ipv4
> address in the same function. We can add the string format in CIDR notation
> as "xxx.xxx.xxx.xxx/yy" where yy is subnet prefix. The mask will be filled
> as a uint32_t same as in ipv4 address.
>
>
>
> syntax will be something like odph_ipv4_addr_parse(uint32_t *ip_addr,
> uint32_t *mask, const char *str)
>
>
> Regards,
> Bala
>
>
>
> On 9 February 2016 at 17:55, Petri Savolainen 
> wrote:
>
> IPv4 address parse function is commonly needed by
> test applications. A common parse function harmonizes the
> definition IPv4 address as a command line parameter.
>
> Signed-off-by: Petri Savolainen 
> ---
>  helper/Makefile.am |   1 +
>  helper/include/odp/helper/ip.h |  22 +-
>  helper/ip.c|  30 
>  helper/test/odp_parse.c| 153
> +
>  4 files changed, 203 insertions(+), 3 deletions(-)
>  create mode 100644 helper/ip.c
>
> diff --git a/helper/Makefile.am b/helper/Makefile.am
> index 22147fa..377a7b9 100644
> --- a/helper/Makefile.am
> +++ b/helper/Makefile.am
> @@ -30,6 +30,7 @@ noinst_HEADERS = \
>
>  __LIB__libodphelper_la_SOURCES = \
> eth.c \
> +   ip.c \
> linux.c \
> ring.c \
> hashtable.c \
> diff --git a/helper/include/odp/helper/ip.h
> b/helper/include/odp/helper/ip.h
> index 2fa4aae..769384f 100644
> --- a/helper/include/odp/helper/ip.h
> +++ b/helper/include/odp/helper/ip.h
> @@ -18,9 +18,7 @@
>  extern "C" {
>  #endif
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
>
>  #include 
> @@ -32,6 +30,7 @@ extern "C" {
>  #define ODPH_IPV4 4  /**< IP version 4 */
>  #define ODPH_IPV4HDR_LEN 20  /**< Min length of IP header (no
> options) */
>  #define ODPH_IPV4HDR_IHL_MIN  5  /**< Minimum IHL value*/
> +#define ODPH_IPV4ADDR_LEN 4  /**< IPv4 address length in bytes */
>
>  /** @internal Returns IPv4 version */
>  #define ODPH_IPV4HDR_VER(ver_ihl) (((ver_ihl) & 0xf0) >> 4)
> @@ -176,6 +175,23 @@ typedef struct ODP_PACKED {
>  /**@}*/
>
>  /**
> + * Parse IPv4 address from a string
> + *
> + * Parses IPv4 address from the string which must be passed in the format
> of
> + * four decimal digits delimited by dots (xxx.xxx.xxx.xxx). All four
> digits
> + * have to be present and may have leading zeros. String does not have to
> be
> + * NULL terminated. The address is written only when successful. The
> address
> + * byte order is CPU native.
> + *
> + * @param[out] ip_addrPointer to IPv4 address for output (in native
> endian)
> + * @param  strIPv4 address string to be parsed
> + *
> + * @retval 0  on success
> + * @retval <0 on failure
> + */
> +int odph_ipv4_addr_parse(uint32_t *ip_addr, const char *str);
> +
> +/**
>   * @}
>   */
>  #ifdef __cplusplus
> diff --git a/hel

Re: [lng-odp] [API-NEXT PATCH] doc: user-guide documentation for classification

[Bala Manoharan]

Hi,

On 15 February 2016 at 20:52, Christophe Milard <
christophe.mil...@linaro.org> wrote:

>
>
> On 15 February 2016 at 15:12, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> Adds user-guide documentation for classification module
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  doc/users-guide/users-guide-cls.adoc | 220
>> +++
>>  1 file changed, 220 insertions(+)
>>  create mode 100644 doc/users-guide/users-guide-cls.adoc
>>
>> diff --git a/doc/users-guide/users-guide-cls.adoc
>> b/doc/users-guide/users-guide-cls.adoc
>> new file mode 100644
>> index 000..3089f86
>> --- /dev/null
>> +++ b/doc/users-guide/users-guide-cls.adoc
>> @@ -0,0 +1,220 @@
>> +== Classification \(CLS)
>> +
>> +ODP is a framework for software-based packet forwarding/filtering
>> applications,
>> +and the purpose of the Packet Classification API is to enable
>> applications to
>> +program the platform hardware or software implementation to assist in
>> +prioritization, classification and scheduling of each packet, so that the
>> +software application can run faster, scale better and adhere to QoS
>> +requirements.
>> +
>> +The following API abstraction are not modelled after any existing product
>> +implementation, but is instead defined in terms of what a typical
>> data-plane
>> +application may require from such a platform, without sacrificing
>> simplicity and
>> +avoiding ambiguity. Certain terms that are being used within the context
>> of
>> +existing products in relation to packet parsing and classification, such
>> as
>> +access lists are avoided such that not to suggest any relationship
>> +between the abstraction used within this API and any particular manner
>> in which
>> +they may be implemented in hardware.
>> +
>> +=== Functional Description
>> +
>> +Following is the functionality that is required of the classification
>> API, and
>> +its underlying implementation. The details and order of the following
>> paragraph
>> +is informative, and is only intended to help convey the functional scope
>> of a
>> +classifier aznd provide context for the API. In reality, implementations
>> may
>>
>
> typo: "and", not aznd
>

Good catch :)

>
>
>> +execute many of these steps concurrently, or in different order while
>> +maintaining the evident dependencies:
>> +
>> +1. Apply a set of classification rules to the header of an incoming
>> packet,
>> +identify the header fields, e.g. ,ethertype, IP version, IP protocol,
>> transport
>> +layer port numbers, IP DiffServ, VLAN id, 802.1p priority.
>> +
>> +2. Store these fields as packet meta data for application use, and for
>> the
>> +remainder of parser operations. The odp_pktio is also stored as one of
>> the meta
>> +data fields for subsequent use.
>> +
>> +3. Compute an odp_cos (Class of Service) value from a subset of
>> supported fields
>> +from 1) above.
>> +
>> +4. Based on the odp_cos from 3) above, select the odp_queue through
>> which the
>> +packet is delivered to the application.
>> +
>> +5. Validate the packet data integrity (checksums, FCS)  and correctness
>> (e.g.,
>> +length fields) and store the validation result, along with optional
>> error layer
>> +and type indicator, in packet meta data. Optionally, if a packet fails
>> +validation, override the odp_cos selection in step 3 to a class of
>> service
>> +designated for errored packets.
>> +
>> +6. Based on the odp_cos from 3) above, select the odp_buffer_pool that
>> should be
>> +used to acquire a buffer to store the packet data and meta data.
>> +
>> +7. Allocate a buffer from odp_buffer_pool selected in 6) above and
>> logically[1]
>> +store the packet data and meta data to the allocated buffer, or in
>> accordance
>> +with class-of-service drop policy and subject to pool buffer
>> availability,
>> +optionally discard the packet.
>> +
>> +8. Enqueue the buffer into the odp_queue selected in 4) above.
>> +
>> +The above is an abstract description of the classifier functionality,
>> and may be
>> +applied to a variety of applications in many different ways. The ultimate
>> +meaning of how this functionality applies to an application also depends
>> on
>> +other ODP modules, so the above may not complete a full depiction. For
>> instance,
>> +the exact meaning of priority, which is a per-queue attribute is
>> influenced by
>> +the ODP scheduler semantics, and the system behavior under stress
>> depends on the
>> +ODP buffer pool module behavior.
>> +
>> +For the sole purpose of illustrating the above abstract functionality,
>> here is
>> +an example of a Layer-2 (IEEE 802.1D)  bridge application: Such a
>> forwarding
>> +application that also adheres to IEEE 802.1p/q priority, which has 8
>> traffic
>> +priority levels, might create 8 odp_buffer_pool instances, one for each
>> PCP
>> +priority level, and 8 odp_queue instances one per priority level.
>> Incoming
>> +packets will be inspected for a VLAN header; the PCP field will be
>> extracted,
>

Re: [lng-odp] crypto contexts

[Bala Manoharan]

Hi,

There is no need to create a crypto session for each packet. The
application needs to create a crypto session for a unique cipher/auth key
(ie all the parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can create a crypto session
and reuse it for packets which need similar processing.  The parameters of
crypto session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
odp_crypto_key_t cipher_key;   /**< Cipher key */
odp_crypto_iv_t  iv;   /**< Cipher Initialization
Vector (IV) */
odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue;   /**< Async mode completion event
queue */
odp_pool_t output_pool;/**< Output buffer pool */
} odp_crypto_session_params_t

If you see the odp_crypto_operation() function it reuses an existing crypto
session and only provides parameters which are unique per packet (ie
cipher/auth range, input packet, etc )

The limit of 32 crypto sessions is a limitation on the linux-generic
implementation and this value might depend on individual platforms.

Regards,
Bala

On 16 February 2016 at 18:40, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

> Hi,
>
> I want to keep up IPSec connections with up to ~100K users simultaneously.
> After looking into the code, it seems that both linux-generic and odp-dpdk
> can allocate at most 32 crypto sessions (with odp_crypto_session_create).
> Please confirm, that this is not a bug, but crypto sessions are considered
> to be a very limited resource and an ODP application should create and
> destroy a crypto session for each packet, when all the users are sending
> traffic at the same time.
> Thanks,
>
> Gabor
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] crypto contexts

[Bala Manoharan]

Hi,

Crypto key in crypto session cannot be changed and in this case you need
'n' different crypto sessions only and it cannot be reused.

Regards,
Bala

On 17 February 2016 at 21:11, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

> How can you change the crypto key? Each user has its own.
>
> Gabor
>
>
> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>
> Hi,
>
> There is no need to create a crypto session for each packet. The
> application needs to create a crypto session for a unique cipher/auth key
> (ie all the parameters in odp_crypto_session_params_t ).
> A crypto session is created so that application can create a crypto
> session and reuse it for packets which need similar processing.  The
> parameters of crypto session are as follows
>
> typedef struct odp_crypto_session_params {
> odp_crypto_op_t op;/**< Encode versus decode */
> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
> ordering */
> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
> odp_crypto_key_t cipher_key;   /**< Cipher key */
> odp_crypto_iv_t  iv;   /**< Cipher Initialization
> Vector (IV) */
> odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
> odp_crypto_key_t auth_key; /**< Authentication key */
> odp_queue_t compl_queue;   /**< Async mode completion
> event queue */
> odp_pool_t output_pool;/**< Output buffer pool */
> } odp_crypto_session_params_t
>
> If you see the odp_crypto_operation() function it reuses an existing
> crypto session and only provides parameters which are unique per packet (ie
> cipher/auth range, input packet, etc )
>
> The limit of 32 crypto sessions is a limitation on the linux-generic
> implementation and this value might depend on individual platforms.
>
> Regards,
> Bala
>
> On 16 February 2016 at 18:40, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
>> Hi,
>>
>> I want to keep up IPSec connections with up to ~100K users
>> simultaneously. After looking into the code, it seems that both
>> linux-generic and odp-dpdk can allocate at most 32 crypto sessions (with
>> odp_crypto_session_create). Please confirm, that this is not a bug, but
>> crypto sessions are considered to be a very limited resource and an ODP
>> application should create and destroy a crypto session for each packet,
>> when all the users are sending traffic at the same time.
>> Thanks,
>>
>> Gabor
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

[Bala Manoharan]

For the series:
Reviewed-by: Balasubramanian Manoharan 

Regards,
Bala

On 18 February 2016 at 01:07, Bill Fischofer 
wrote:

> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/spec/crypto.h | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index 41beedb..eaacff1 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
>  } odp_crypto_op_result_t;
>
>  /**
> + * Crypto capabilities
> + */
> +typedef struct odp_crypto_capability_t {
> +   /** Maximum number of sessions */
> +   unsigned max_sessions;
> +} odp_crypto_capability_t;
> +
> +/**
> + * Get crypto capabilities
> + *
> + * @param[out] capability Pointer to capability structrue for output
> + *
> + * @retval 0 on success
> + * @retval <0 on failure
> + */
> +int odp_crypto_capability(odp_crypto_capability_t *capability);
> +
> +/**
>   * Crypto session creation (synchronous)
>   *
>   * @param paramsSession parameters
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] crypto contexts

[Bala Manoharan]

On 18 February 2016 at 13:58, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

> OK, so back to the original question: I have up to ~100K users (but always
> higher than 32 by orders of magnitude) all with its own crypto key. In
> worst case, all of them are sending packets at the same time, so I need to
> decrypt a lot of packets from other users, before I face a packet from the
> same user again, so I cannot have 'n' different sessions. Since I cannot
> change the crypto key, the only way to do this is creating and destroying a
> session per packet. I looked into the x86 code, and it seemed that the code
> was intentionally written in a way that session create/destroy is
> relatively quick, since there is no malloc and free and crypto contexts are
> not destroyed at all.
>
> I think, there are three possibilities at this point:
> 1. ODP was intentionally designed in the way that creating/destroying
> crypto session is fast, i.e. I can expect that this is a cheap operation on
> each platform.
>
2. This is just a bug in API, and should be fixed by adding some way to
> change the crypto key.
> 3. There is already some solution, which I don't know... E.g. the
> cipher_key.data field in the session is just a pointer, one possibility is
> changing the memory content at the address where it points to. :)
>
> Please confirm that #1 is the correct answer.
>
> Gabor
>


Unfortunately the method in which crypto session is created/destroyed is
implementation specific it might be faster but I personally wouldn't bet on
this. Since as discussed earlier the idea of crypto session is only to
reuse the parameters during odp_cryto_operation() function for better
performance so crypto session create/destroy might not be upto the mark
required in a fast path execution.

IMO there is two possible ways to address your use-case,
1. add override_cipher_key and override_auth_key parameters to
odp_crypto_op_params_t  struct which is an input to odp_cryto_operations()
function so that if these value is a not-null then the implementation will
override the values in crypto session but the drawback of this approach is
that then for general use-case where the cipher/auth key is same per
session the implementation will always have to check the
override_cipher_key/override_auth_key parameter which actually is just a
simple check but since this code runs in fast path and it is per packet
might impact the performance.

2. A more preferable approach in my point of view is to add a new API
odp_crypto_operation_key() where cipher key and auth key are given as input
parameter along with session so that the applications which need to pass
individual cipher/auth key per user can use this new API so that the
performance of  odp_crypto_operation() is not changed.

your suggestions/ comments are most welcome and I will send an RFC based on
option 2 for further discussion and you can provide your comments on the
same.

Regards,
Bala


>
>
> On 02/17/2016 05:56 PM, Bala Manoharan wrote:
>
> Hi,
>
> Crypto key in crypto session cannot be changed and in this case you need
> 'n' different crypto sessions only and it cannot be reused.
>
> Regards,
> Bala
>
> On 17 February 2016 at 21:11, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
>> How can you change the crypto key? Each user has its own.
>>
>> Gabor
>>
>>
>> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>>
>> Hi,
>>
>> There is no need to create a crypto session for each packet. The
>> application needs to create a crypto session for a unique cipher/auth key
>> (ie all the parameters in odp_crypto_session_params_t ).
>> A crypto session is created so that application can create a crypto
>> session and reuse it for packets which need similar processing.  The
>> parameters of crypto session are as follows
>>
>> typedef struct odp_crypto_session_params {
>> odp_crypto_op_t op;/**< Encode versus decode */
>> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
>> ordering */
>> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
>> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
>> odp_crypto_key_t cipher_key;   /**< Cipher key */
>> odp_crypto_iv_t  iv;   /**< Cipher Initialization
>> Vector (IV) */
>> odp_auth_alg_t auth_alg;   /**< Authentication algorithm
>> */
>> odp_crypto_key_t auth_key; /**< Authentication key */
>> odp_queue_t compl_queue;   /**< Async mode completion
>> event queue */
>> odp_pool_t output_pool;  

Re: [lng-odp] crypto contexts

[Bala Manoharan]

Hi Nikhil,

On 18 February 2016 at 15:24, Nikhil Agarwal  wrote:

> Hi,
>
>
>
> It seems none of your statement is true.  Comments inline.
>
> It is platform implementation specific that how many crypto sessions it
> supports. If it does not support required number of sessions, then only way
> out as of today is to create n destroy session.
>
>
>
> Bala,
>
>
>
> If this is a generic use-case, shall a  light weight modify session API be
> considered to be added, as 100K session might be costly to maintain,
> provided they are used only once in a long run?
>

Agreed.100K session might be very costly to maintain and might defeat the
purpose of creating crypto session. The user in that case might very well
given all the session parameters to odp_crypto_operation() function.

IMO modify crypto session might not be a good idea since there might be
packets inflight which are using a particular session and changing the
session parameter creates ambiguity for packets under processing.

Regards,
Bala

>
>
> Regards
>
> Nikhil
>
>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *Gábor
> Sándor Enyedi
> *Sent:* Thursday, February 18, 2016 1:58 PM
> *To:* Bala Manoharan 
> *Cc:* lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] crypto contexts
>
>
>
> OK, so back to the original question: I have up to ~100K users (but always
> higher than 32 by orders of magnitude) all with its own crypto key. In
> worst case, all of them are sending packets at the same time, so I need to
> decrypt a lot of packets from other users, before I face a packet from the
> same user again, so I cannot have 'n' different sessions. Since I cannot
> change the crypto key, the only way to do this is creating and destroying a
> session per packet. I looked into the x86 code, and it seemed that the code
> was intentionally written in a way that session create/destroy is
> relatively quick, since there is no malloc and free and crypto contexts are
> not destroyed at all.
>
> I think, there are three possibilities at this point:
> 1. ODP was intentionally designed in the way that creating/destroying
> crypto session is fast, i.e. I can expect that this is a cheap operation on
> each platform.
>
> [Nikhil] This is implementation specific, and cannot be guaranteed to be
> fast on each platform.(As this is supposed to be one time API per session)
> 2. This is just a bug in API, and should be fixed by adding some way to
> change the crypto key.
>
> [Nikhil] You cannot change crypto key for a session.
> 3. There is already some solution, which I don't know... E.g. the
> cipher_key.data field in the session is just a pointer, one possibility is
> changing the memory content at the address where it points to. :)
>
> [Nikhil] There is no way as of today that you can modify crypto keys of a
> session.
>
>
>
> Please confirm that #1 is the correct answer.
>
> Gabor
>
> On 02/17/2016 05:56 PM, Bala Manoharan wrote:
>
> Hi,
>
>
>
> Crypto key in crypto session cannot be changed and in this case you need
> 'n' different crypto sessions only and it cannot be reused.
>
>
>
> Regards,
>
> Bala
>
> On 17 February 2016 at 21:11, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
> How can you change the crypto key? Each user has its own.
>
> Gabor
>
>
>
> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>
> Hi,
>
>
>
> There is no need to create a crypto session for each packet. The
> application needs to create a crypto session for a unique cipher/auth key
> (ie all the parameters in odp_crypto_session_params_t ).
>
> A crypto session is created so that application can create a crypto
> session and reuse it for packets which need similar processing.  The
> parameters of crypto session are as follows
>
>
>
> typedef struct odp_crypto_session_params {
>
> odp_crypto_op_t op;/**< Encode versus decode */
>
> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
> ordering */
>
> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
>
> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
>
> odp_crypto_key_t cipher_key;   /**< Cipher key */
>
> odp_crypto_iv_t  iv;   /**< Cipher Initialization
> Vector (IV) */
>
> odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
>
> odp_crypto_key_t auth_key; /**< Authentication key */
>
> odp_queue_t compl_queue;   /**< Async mode completion
> event queue */
>
> 

Re: [lng-odp] [PATCH] Provide a generic function to invalidate a queue.

[Bala Manoharan]

On 22 February 2016 at 18:04, José Pekkarinen 
wrote:

> To provide support of different definitions of odp_queue_t
> it's good to have a proper mechanism to set the queue invalid
> in case any error during the transmission happen.
>

What is the expectation from the implementation when an application
invalidates a queue?
The linux-generic implementation does not actually do anything.

Regards,
Bala

>
> This eases the case when odp_queue_t is defined as an union
> and the type of this queue is set as a member of the given
> union.
>
> Signed-off-by: José Pekkarinen 
> ---
>  include/odp/api/queue.h| 10 ++
>  platform/linux-generic/odp_queue.c | 10 ++
>  2 files changed, 20 insertions(+)
>
> diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h
> index bde8ca3..95eaf3b 100644
> --- a/include/odp/api/queue.h
> +++ b/include/odp/api/queue.h
> @@ -371,6 +371,16 @@ typedef struct odp_queue_info_t {
>  int odp_queue_info(odp_queue_t queue, odp_queue_info_t *info);
>
>  /**
> + * Invalidate a queue
> + *
> + * @param  queue   Queue handle
> + *
> + * @retval 0 Success
> + * @retval <0 Failure. Queue could not be invalidated.
> + */
> +int odp_queue_invalidate(odp_queue_t queue);
> +
> +/**
>   * @}
>   */
>
> diff --git a/platform/linux-generic/odp_queue.c
> b/platform/linux-generic/odp_queue.c
> index dbe2d9c..591cc79 100644
> --- a/platform/linux-generic/odp_queue.c
> +++ b/platform/linux-generic/odp_queue.c
> @@ -1116,3 +1116,13 @@ int odp_queue_info(odp_queue_t handle,
> odp_queue_info_t *info)
>
> return 0;
>  }
> +
> +int odp_queue_invalidate(odp_queue_t handle)
> +{
> +   if(handle = ODP_QUEUE_INVALID){
> +   ODP_ERR("Queue could not be invalidated\n");
> +   return -1;
> +   }
> +
> +   return 0;
> +}
> --
> 2.4.10
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT v3] doc: user-guide documentation for classification

[Bala Manoharan]

On 25 February 2016 at 18:14, Christophe Milard <
christophe.mil...@linaro.org> wrote:

>
>
> On 25 February 2016 at 09:56, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> v3: Incorporates classification user guide to main document
>> Adds Practical example section
>> v2: Incorporates review comments from Christophe
>>  doc/users-guide/users-guide-cls.adoc | 220
>> +++
>>  doc/users-guide/users-guide.adoc |   2 +
>>  2 files changed, 222 insertions(+)
>>  create mode 100644 doc/users-guide/users-guide-cls.adoc
>>
>> diff --git a/doc/users-guide/users-guide-cls.adoc
>> b/doc/users-guide/users-guide-cls.adoc
>> new file mode 100644
>> index 000..8dd8f76
>> --- /dev/null
>> +++ b/doc/users-guide/users-guide-cls.adoc
>> @@ -0,0 +1,220 @@
>> +== Classification (CLS)
>> +
>> +ODP is a framework for software-based packet forwarding/filtering
>> applications,
>> +and the purpose of the Packet Classification API is to enable
>> applications to
>> +program the platform hardware or software implementation to assist in
>> +prioritization, classification and scheduling of each packet, so that the
>> +software application can run faster, scale better and adhere to QoS
>> +requirements.
>> +
>> +The following API abstraction are not modelled after any existing product
>> +implementation, but is instead defined in terms of what a typical
>> data-plane
>> +application may require from such a platform, without sacrificing
>> simplicity and
>> +avoiding ambiguity. Certain terms that are being used within the context
>> of
>> +existing products in relation to packet parsing and classification, such
>> as
>> +access lists are avoided such that not to suggest any relationship
>> +between the abstraction used within this API and any particular manner
>> in which
>> +they may be implemented in hardware.
>> +
>> +=== Functional Description
>> +
>> +Following is the functionality that is required of the classification
>> API, and
>> +its underlying implementation. The details and order of the following
>> paragraph
>> +is informative, and is only intended to help convey the functional scope
>> of a
>> +classifier and provide context for the API. In reality, implementations
>> may
>> +execute many of these steps concurrently, or in different order while
>> +maintaining the evident dependencies:
>> +
>> +1. Apply a set of classification rules to the header of an incoming
>> packet,
>> +identify the header fields, e.g. ,ethertype, IP version, IP protocol,
>> transport
>> +layer port numbers, IP DiffServ, VLAN id, 802.1p priority.
>> +
>> +2. Store these fields as packet meta data for application use, and for
>> the
>> +remainder of parser operations. The odp_pktio is also stored as one of
>> the meta
>> +data fields for subsequent use.
>> +
>> +3. Compute an odp_cos (Class of Service) value from a subset of
>> supported fields
>> +from 1) above.
>> +
>> +4. Based on the odp_cos from 3) above, select the odp_queue through
>> which the
>> +packet is delivered to the application.
>> +
>> +5. Validate the packet data integrity (checksums, FCS)  and correctness
>> (e.g.,
>> +length fields) and store the validation result, along with optional
>> error layer
>> +and type indicator, in packet meta data. Optionally, if a packet fails
>> +validation, override the odp_cos selection in step 3 to a class of
>> service
>> +designated for errored packets.
>> +
>> +6. Based on the odp_cos from 3) above, select the odp_buffer_pool that
>> should be
>> +used to acquire a buffer to store the packet data and meta data.
>> +
>> +7. Allocate a buffer from odp_buffer_pool selected in 6) above and
>> logically[1]
>> +store the packet data and meta data to the allocated buffer, or in
>> accordance
>> +with class-of-service drop policy and subject to pool buffer
>> availability,
>> +optionally discard the packet.
>> +
>> +8. Enqueue the buffer into the odp_queue selected in 4) above.
>> +
>> +The above is an abstract description of the classifier functionality,
>> and may be
>> +applied to a variety of applications in many different ways. The ultimate
>> +meaning of how this functionality applies to an application also depends
>> on
>> +other ODP modules, so the above may not complete a full depiction. For
>> instance,
>> +the exact meaning of priority, which is a per-queue attribute is
>> influenced by
>> +the ODP scheduler semantics, and the system behavior under stress
>> depends on the
>> +ODP buffer pool module behavior.
>> +
>> +For the sole purpose of illustrating the above abstract functionality,
>> here is
>> +an example of a Layer-2 (IEEE 802.1D)  bridge application: Such a
>> forwarding
>> +application that also adheres to IEEE 802.1p/q priority, which has 8
>> traffic
>> +priority levels, might create 8 odp_buffer_pool instances, one for each
>> PCP
>> +priority level, and 8 odp_queue instances one per priority level.
>> Incoming
>> 

Re: [lng-odp] [PATCH] Provide a generic function to invalidate a queue.

[Bala Manoharan]

Regards,
Bala

On 26 February 2016 at 11:51, José Pekkarinen 
wrote:

> On Thursday 25 February 2016 15:01:11 EXT Bill Fischofer wrote:
>
> > On Thu, Feb 25, 2016 at 12:39 PM, José Pekkarinen <
> jose.pekkari...@nokia.com
>
> > > wrote:
>
> > >
>
> > > On Thursday 25 February 2016 11:54:31 EXT Bill Fischofer wrote:
>
> > > > Anything with an initial underscore (like _odp_cast_scalar()) is an
>
> > > >
>
> > > > implementation-internal API (in this case, linux-generic) and is most
>
> > > >
>
> > > > definitely neither portable nor subject to any release-to-release
>
> > > >
>
> > > > compatibility guarantees, so I'd highly discourage trying to use
> them.
>
> > >
>
> > > It's used under the scope of the platform folder of odp, not outside of
>
> > > that, and just limited to this usecase, where some vendor decides that
>
> > > want
>
> > > to use unions to define types that linux-generic does with other kind
> of
>
> > > data structure.
>
> > >
>
> > > > If I understand your use case correctly, you want to create a queue
> but
>
> > > >
>
> > > > (perhaps temporarily) put it into a state where other queue
> operations
>
> > > > on
>
> > > >
>
> > > > it are rejected? We've previously talked about defining an
>
> > > >
>
> > > > odp_queue_quiesce() API that would prohibit further enqueues to a
> queue
>
> > > >
>
> > > > while still permitting existing elements to be dequeued from it.
> This to
>
> > > >
>
> > > > support graceful termination where you want to drain a queue before
>
> > > >
>
> > > > destroying it. A corresponding odp_queue_resume() call would return a
>
> > > >
>
> > > > quiesced queue to normal operation. Would such a capability suffice
> for
>
> > > >
>
> > > > your use case or are you also looking to reject dequeue and/or
> destroy
>
> > > >
>
> > > > operations on the queue while it is "invalid"? Also, wouldn't you
> need a
>
> > > >
>
> > > > odp_queue_revalidate() API to bookend odp_queue_invalidate()?
>
> > >
>
> > > The situation is the other way around. When we create an interface, the
>
> > > structure defines the queues, and it will initialize all it's data
>
> > > structure one after another, until it gets to the end of the
>
> > > initialization
>
> > > or some initialization error happens. If the queue is created
> correctly,
>
> > > but some problem in the initialization happens later on, the queue is
>
> > > cleaned up setting it to invalid until we can memset the structure.
> This
>
> > > is
>
> > > valid also when you happen to have corruption in the queue, or failures
>
> > > sending some packets through the queue(burst failures, etc).
>
> >
>
> > If your structure contains an odp_queue_t handle in it, then that
> variable
>
> > can always be set to ODP_QUEUE_INVALID, which is the designated portable
>
> > handle value to indicate an invalid queue.
>
>
>
> And this is what we want, to have more flexibility to set this to invalid,
> as the only way to do a pure assignation to ODP_QUEUE_INVALID for unions is
> setting ODP_QUEUE_INVALID as stated in the following line.
>
>
>
> #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, ~(unsigned)0)
>
>
>
> > If you have created the queue
>
> > via odp_queue_create() and received a handle for it then you at some
> point
>
> > need to do a corresponding odp_queue_destroy() queue to free up any ODP
>
> > resources associated with that queue. Simply throwing away the handle
>
> > would result in resource leakage.
>
>
>
> Sure, odp_queue_destroy should be called, but it takes more processing
> time than just setting the queue to invalid, and it can be performed when
> no demanding network load is coming.
>

If the queue is successfully create by the implementation and a valid queue
handle is returned then odp_queue_destroy() function is required to clear
any HW resources allocated by the implementation. So that handle cannot be
set to invalid by the application.

Regards,
Bala

>
>
> Best regards.
>
>
>
> José.
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] Provide a generic function to invalidate a queue.

[Bala Manoharan]

Regards,
Bala

On 26 February 2016 at 12:41, José Pekkarinen 
wrote:

>
>
> Hi,
>
>
>
> > > And this is what we want, to have more flexibility to set this to
> invalid,
>
> > > as the only way to do a pure assignation to ODP_QUEUE_INVALID for
> unions
>
> > > is
>
> > > setting ODP_QUEUE_INVALID as stated in the following line.
>
> > >
>
> > >
>
> > >
>
> > > #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, ~(unsigned)0)
>
> > >
>
> > > > If you have created the queue
>
> > > >
>
> > > > via odp_queue_create() and received a handle for it then you at some
>
> > >
>
> > > point
>
> > >
>
> > > > need to do a corresponding odp_queue_destroy() queue to free up any
> ODP
>
> > > >
>
> > > > resources associated with that queue. Simply throwing away the handle
>
> > > >
>
> > > > would result in resource leakage.
>
> > >
>
> > > Sure, odp_queue_destroy should be called, but it takes more processing
>
> > > time than just setting the queue to invalid, and it can be performed
> when
>
> > > no demanding network load is coming.
>
> >
>
> > If the queue is successfully create by the implementation and a valid
> queue
>
> > handle is returned then odp_queue_destroy() function is required to clear
>
> > any HW resources allocated by the implementation. So that handle cannot
> be
>
> > set to invalid by the application.
>
> >
>
>
>
> Yes, that is for sure, but does it have to be cleaned up immediately? Is
> there no way to delay the processing of the destroy function until we are
> not in a hurry?
>

That depends on your application since if you are delaying cleaning up a
queue you might actually deny creating new queue as the platform might
overruns the total amount of queue supported.

Also just to be clear, odp handles are opaque to the application and it
does not have the right to set the handle to INVALID directly. It has to go
through the implementation to INVALIDATE a handle and currently the only
way is to call odp_xxx_destroy() API.

Regards,
Bala

>
>
> Best regards.
>
>
>
> José.
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT v3] doc: user-guide documentation for classification

[Bala Manoharan]

Hi Christophe,

I have merged the changes you had proposed and have sent an updated version.
I have also added your signed-off to the new version as discussed.

Regards,
Bala

On 29 February 2016 at 13:25, Christophe Milard <
christophe.mil...@linaro.org> wrote:

> Hi Bala. Just sent you a patch that you can apply on the top of this to
> correct a few formating issues.I assume you will agree. You can sent V6
> with my review (see patch comments), as this document makes sense to me. It
> would be nice to add  a section on writting PMRs (with code exemples) in
> the future. But that can be another patch.
> Sorry for the number of iterations :-). I won't re-read the v6!
>
> Christophe.
>
> On 25 February 2016 at 09:56, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> v3: Incorporates classification user guide to main document
>> Adds Practical example section
>> v2: Incorporates review comments from Christophe
>>  doc/users-guide/users-guide-cls.adoc | 220
>> +++
>>  doc/users-guide/users-guide.adoc |   2 +
>>  2 files changed, 222 insertions(+)
>>  create mode 100644 doc/users-guide/users-guide-cls.adoc
>>
>> diff --git a/doc/users-guide/users-guide-cls.adoc
>> b/doc/users-guide/users-guide-cls.adoc
>> new file mode 100644
>> index 000..8dd8f76
>> --- /dev/null
>> +++ b/doc/users-guide/users-guide-cls.adoc
>> @@ -0,0 +1,220 @@
>> +== Classification (CLS)
>> +
>> +ODP is a framework for software-based packet forwarding/filtering
>> applications,
>> +and the purpose of the Packet Classification API is to enable
>> applications to
>> +program the platform hardware or software implementation to assist in
>> +prioritization, classification and scheduling of each packet, so that the
>> +software application can run faster, scale better and adhere to QoS
>> +requirements.
>> +
>> +The following API abstraction are not modelled after any existing product
>> +implementation, but is instead defined in terms of what a typical
>> data-plane
>> +application may require from such a platform, without sacrificing
>> simplicity and
>> +avoiding ambiguity. Certain terms that are being used within the context
>> of
>> +existing products in relation to packet parsing and classification, such
>> as
>> +access lists are avoided such that not to suggest any relationship
>> +between the abstraction used within this API and any particular manner
>> in which
>> +they may be implemented in hardware.
>> +
>> +=== Functional Description
>> +
>> +Following is the functionality that is required of the classification
>> API, and
>> +its underlying implementation. The details and order of the following
>> paragraph
>> +is informative, and is only intended to help convey the functional scope
>> of a
>> +classifier and provide context for the API. In reality, implementations
>> may
>> +execute many of these steps concurrently, or in different order while
>> +maintaining the evident dependencies:
>> +
>> +1. Apply a set of classification rules to the header of an incoming
>> packet,
>> +identify the header fields, e.g. ,ethertype, IP version, IP protocol,
>> transport
>> +layer port numbers, IP DiffServ, VLAN id, 802.1p priority.
>> +
>> +2. Store these fields as packet meta data for application use, and for
>> the
>> +remainder of parser operations. The odp_pktio is also stored as one of
>> the meta
>> +data fields for subsequent use.
>> +
>> +3. Compute an odp_cos (Class of Service) value from a subset of
>> supported fields
>> +from 1) above.
>> +
>> +4. Based on the odp_cos from 3) above, select the odp_queue through
>> which the
>> +packet is delivered to the application.
>> +
>> +5. Validate the packet data integrity (checksums, FCS)  and correctness
>> (e.g.,
>> +length fields) and store the validation result, along with optional
>> error layer
>> +and type indicator, in packet meta data. Optionally, if a packet fails
>> +validation, override the odp_cos selection in step 3 to a class of
>> service
>> +designated for errored packets.
>> +
>> +6. Based on the odp_cos from 3) above, select the odp_buffer_pool that
>> should be
>> +used to acquire a buffer to store the packet data and meta data.
>> +
>> +7. Allocate a buffer from odp_buffer_pool selected in 6) above and
>> logically[1]
>> +store the packet data and meta data to the allocated buffer, or in
>> accordance
>> +with class-of-service drop policy and subject to pool buffer
>> availability,
>> +optionally discard the packet.
>> +
>> +8. Enqueue the buffer into the odp_queue selected in 4) above.
>> +
>> +The above is an abstract description of the classifier functionality,
>> and may be
>> +applied to a variety of applications in many different ways. The ultimate
>> +meaning of how this functionality applies to an application also depends
>> on
>> +other ODP modules, so the above may not complete a full depiction. For
>> instance,
>> +the exact meaning of priority, w

Re: [lng-odp] [API-NEXT PATCHv1] linux-generic:pktio:add an interface to support multi pool

[Bala Manoharan]

Hi,

The above described use-case is implementable with the existing ODP
classification framework.

Few points to take note for implementing this use-case
* Each CoS has an associated pool from which packets arriving at this CoS
is allocated.
* There is an existing PMR rule ODP_PMR_LEN which selects packets based on
the total length of received packets.

example:
An application can create different PMR rules with term ODP_PMR_LEN each
associated with different CoSs. When packets of different length arrive at
the pktio interface they will be associated to their respective CoS based
on the PMR rules (in this case ODP_PMR_LEN). Since each CoS has an
associated pool then these packets which have been differentiated based on
their length will be allocated on the pool associated with the CoS.

Hope this Helps,
Bala

On 29 February 2016 at 15:58, huanggaoyang  wrote:

> Make the packet IO interface support multi packet pools with different
> buffer size.
> When receiving packets, the pktio will alloc packets from the most
> suitable pool via packet len.
>
> It aims to save the memory in case that the Memory Resource is limited,
> and the pktio
> should deal with packets in different length.
>
> huanggaoyang (1):
>   linux-generic:pktio:add an interface to support multi pool
>
>  include/odp/api/packet_io.h| 15 +
>  .../linux-generic/include/odp_packet_io_internal.h |  1 +
>  platform/linux-generic/include/odp_packet_tap.h|  5 +-
>  platform/linux-generic/odp_packet_io.c | 16 +
>  platform/linux-generic/pktio/tap.c | 70
> --
>  test/validation/pktio/pktio.c  | 63
> ++-
>  test/validation/pktio/pktio.h  |  1 +
>  7 files changed, 163 insertions(+), 8 deletions(-)
>
> --
> 1.9.1
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT v6] doc: user-guide documentation for classification

[Bala Manoharan]

Hi Maxim,

Can you please merge this patch.

Regards,
Bala

On 1 March 2016 at 08:53, Bill Fischofer  wrote:

> One small typo noted.  Other than that:
>
> Reviewed-and-tested-by: Bill Fischofer 
>
>
> On Mon, Feb 29, 2016 at 7:16 AM, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> User guide documentation for classification
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> Reviewed-by: Christophe Milard 
>> ---
>> v6: Incorporates format changes done by Christophe
>> v5: Proper documentation for example code
>> v4: Adds example code into source code section
>> v3: Incorporates classification user guide to main document
>> Adds Practical example section
>> v2: Incorporates review comments from Christophe
>>  doc/users-guide/users-guide-cls.adoc | 224
>> +++
>>  doc/users-guide/users-guide.adoc |   2 +
>>  2 files changed, 226 insertions(+)
>>  create mode 100644 doc/users-guide/users-guide-cls.adoc
>>
>> diff --git a/doc/users-guide/users-guide-cls.adoc
>> b/doc/users-guide/users-guide-cls.adoc
>> new file mode 100644
>> index 000..9e433f2
>> --- /dev/null
>> +++ b/doc/users-guide/users-guide-cls.adoc
>> @@ -0,0 +1,224 @@
>> +== Classification (CLS)
>> +
>> +ODP is a framework for software-based packet forwarding/filtering
>> applications,
>> +and the purpose of the Packet Classification API is to enable
>> applications to
>> +program the platform hardware or software implementation to assist in
>> +prioritization, classification and scheduling of each packet, so that the
>> +software application can run faster, scale better and adhere to QoS
>> +requirements.
>> +
>> +The following API abstraction are not modelled after any existing product
>> +implementation, but is instead defined in terms of what a typical
>> data-plane
>> +application may require from such a platform, without sacrificing
>> simplicity and
>> +avoiding ambiguity. Certain terms that are being used within the context
>> of
>> +existing products in relation to packet parsing and classification, such
>> as
>> +access lists are avoided such that not to suggest any relationship
>> +between the abstraction used within this API and any particular manner
>> in which
>> +they may be implemented in hardware.
>> +
>> +=== Functional Description
>> +
>> +Following is the functionality that is required of the classification
>> API, and
>> +its underlying implementation. The details and order of the following
>> paragraph
>> +is informative, and is only intended to help convey the functional scope
>> of a
>> +classifier and provide context for the API. In reality, implementations
>> may
>> +execute many of these steps concurrently, or in different order while
>> +maintaining the evident dependencies:
>> +
>> +1. Apply a set of classification rules to the header of an incoming
>> packet,
>> +identify the header fields, e.g. ethertype, IP version, IP protocol,
>> transport
>> +layer port numbers, IP DiffServ, VLAN id, 802.1p priority.
>> +
>> +2. Store these fields as packet meta data for application use, and for
>> the
>> +remainder of parser operations. The odp_pktio is also stored as one of
>> the meta
>> +data fields for subsequent use.
>> +
>> +3. Compute an odp_cos (Class of Service) value from a subset of
>> supported fields
>> +from 1) above.
>> +
>> +4. Based on the odp_cos from 3) above, select the odp_queue through
>> which the
>> +packet is delivered to the application.
>> +
>> +5. Validate the packet data integrity (checksums, FCS)  and correctness
>> (e.g.,
>> +length fields) and store the validation result, along with optional
>> error layer
>> +and type indicator, in packet meta data. Optionally, if a packet fails
>> +validation, override the odp_cos selection in step 3 to a class of
>> service
>> +designated for errored packets.
>> +
>> +6. Based on the odp_cos from 3) above, select the odp_buffer_pool that
>> should be
>> +used to acquire a buffer to store the packet data and meta data.
>> +
>> +7. Allocate a buffer from odp_buffer_pool selected in 6) above and
>> logically[1]
>> +store the packet data and meta data to the allocated buffer, or in
>> accordance
>> +with class-of-service drop policy and subject to pool buffer
>> availability,
>> +optionally discard the packet.
>> +
>> +8. Enqueue the buffer into the odp_queue selected in 4) above.
>> +
>> +The above is an abstract description of the classifier functionality,
>> and may be
>> +applied to a variety of applications in many different ways. The ultimate
>> +meaning of how this functionality applies to an application also depends
>> on
>> +other ODP modules, so the above may not complete a full depiction. For
>> instance,
>> +the exact meaning of priority, which is a per-queue attribute is
>> influenced by
>> +the ODP scheduler semantics, and the system behavior under stress
>> depends on the
>> +ODP buffer pool module behavior.
>> +
>> +For the sole purpose of illustrating the above abstract functionality,
>> 

Re: [lng-odp] [PATCH v1] validation: classification: add test case for odp_cos_drop() function

[Bala Manoharan]

Ping

Regards,
Bala

On 18 February 2016 at 18:18, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:

> Fixes: https://bugs.linaro.org/show_bug.cgi?id=2016
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  test/validation/classification/odp_classification_basic.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/test/validation/classification/odp_classification_basic.c
> b/test/validation/classification/odp_classification_basic.c
> index 81077b6..8fbad5f 100644
> --- a/test/validation/classification/odp_classification_basic.c
> +++ b/test/validation/classification/odp_classification_basic.c
> @@ -215,8 +215,11 @@ void classification_test_cos_set_drop(void)
>
> retval = odp_cos_drop_set(cos_drop, ODP_COS_DROP_POOL);
> CU_ASSERT(retval == 0);
> +   CU_ASSERT(ODP_COS_DROP_POOL == odp_cos_drop(cos_drop));
> +
> retval = odp_cos_drop_set(cos_drop, ODP_COS_DROP_NEVER);
> CU_ASSERT(retval == 0);
> +   CU_ASSERT(ODP_COS_DROP_NEVER == odp_cos_drop(cos_drop));
> odp_cos_destroy(cos_drop);
> odp_pool_destroy(pool);
> odp_queue_destroy(queue);
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv1] linux-generic:pktio:add an interface to support multi pool

[Bala Manoharan]

The concept of range for Packet matching terms was initially proposed in
classification and was removed since most HW implement packet classifier
using TCAM and TCAMs only support matching and mask.

The range can be configured using the existing PMR by intelligently
configuring the system by using bit mask parameters in PMR.

Let us take a simple example:
PMR1 -- Term value = 0x and mask 0x00FF
PMR2 -- Term value = 0x0100 and mask 0x01FF
PMR3 -- Term value = 0x0200 and mask 0x02FF

PMR1 will match all packet with the length range 0 to 255 bytes
PMR2 will match all packets with the length range 256 to 511 bytes
PMR3 will match all packets with the length range 512 to 767 bytes

And the default CoS will receive all the remaining packets with higher
lengths.

Regards,
Bala

On 3 March 2016 at 09:11, huanggaoyang  wrote:

> Hi,
> Thank you for your explaining. But I can't totally agree with you.
> I don't know how does the ODP_PMR_LEN support range match.
> I mean if I want the packets with different lenth alloced from Pool No1~4
> like this:
>   lenthalloc from
> (0, 200)Pool-No.1
> [200, 800)Pool-No.2
> [800, 1600)  Pool-No.3
> other  Pool-No.4
> How can I create  pair to implement this?
>
>
> 在 2016/3/1 23:27, Bala Manoharan 写道:
>
> Hi,
>
> The above described use-case is implementable with the existing ODP
> classification framework.
>
> Few points to take note for implementing this use-case
> * Each CoS has an associated pool from which packets arriving at this CoS
> is allocated.
> * There is an existing PMR rule ODP_PMR_LEN which selects packets based on
> the total length of received packets.
>
> example:
> An application can create different PMR rules with term ODP_PMR_LEN each
> associated with different CoSs. When packets of different length arrive at
> the pktio interface they will be associated to their respective CoS based
> on the PMR rules (in this case ODP_PMR_LEN). Since each CoS has an
> associated pool then these packets which have been differentiated based on
> their length will be allocated on the pool associated with the CoS.
>
> Hope this Helps,
> Bala
>
> On 29 February 2016 at 15:58, huanggaoyang 
> wrote:
>
>> Make the packet IO interface support multi packet pools with different
>> buffer size.
>> When receiving packets, the pktio will alloc packets from the most
>> suitable pool via packet len.
>>
>> It aims to save the memory in case that the Memory Resource is limited,
>> and the pktio
>> should deal with packets in different length.
>>
>> huanggaoyang (1):
>>   linux-generic:pktio:add an interface to support multi pool
>>
>>  include/odp/api/packet_io.h| 15 +
>>  .../linux-generic/include/odp_packet_io_internal.h |  1 +
>>  platform/linux-generic/include/odp_packet_tap.h|  5 +-
>>  platform/linux-generic/odp_packet_io.c | 16 +
>>  platform/linux-generic/pktio/tap.c | 70
>> --
>>  test/validation/pktio/pktio.c  | 63
>> ++-
>>  test/validation/pktio/pktio.h  |  1 +
>>  7 files changed, 163 insertions(+), 8 deletions(-)
>>
>> --
>> 1.9.1
>>
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
> ___
> lng-odp mailing 
> listlng-odp@lists.linaro.orghttps://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv1] linux-generic:pktio:add an interface to support multi pool

[Bala Manoharan]

Hi,

I think I made a mistake while configuring Mask in the above example. My
Bad :)

This is the exact configuration which should be given as input to PMR
creation for the example defined above.


PMR1 -- Term value = 0x and mask 0xFF00
PMR2 -- Term value = 0x0100 and mask 0xFF00
PMR3 -- Term value = 0x0200 and mask 0xFF00
Val_sz is 16 bits.

'Val_sz' denotes the size of 'value' and 'Mask' in the specific term.

The 'Value' is the value to be matched against the packet header in native
byte order the 'Mask' is used to indicate which bits in the header is
matched (1's) and which should be ignored (0's).
The logic is based on ternary CAM where memory has the ability to query
three different inputs: 0, 1, and X.  where input 'x' point to don't care
or ignore.
So for a given value and mask combination the effective set is calculated
as:
Input set to be matched = value & mask.

So if the term length is 16 bits and the following are inputs:
Value = 0x
Mask = 0xFF00
, then the effective set which is mapped is (value & mask).
In the above case ( 0x & 0xFF00) which is 0x00XX.

For the input set of 0x00XX to a TCAM then it matches all the values from
0x to 0x00FF.

Based on the defined logic if Value = 0x0200 and Mask = 0xFF00
input set = 0x02XX and will match all the values from 0x0200 to 0x02FF.
Hence a packet of length 0x1200 will go to the default CoS.

Regards,
Bala

On 4 March 2016 at 06:59, huanggaoyang  wrote:

> I don't think the PMR1~3 in your example will work like you said.
> If the incoming packet len is 0x1200:
> 0x1200 & 0x00FF(PMR1's mask)==0x, so the packet matchs PMR1...
> 0x1200 & 0x02FF(PMR3's mask)==0x0200, also matchs PMR3...
>
> But actually I want this 0x1200 packet match the Default Cos's PMR
>
>
> 在 2016/3/3 21:35, Bala Manoharan 写道:
>
> The concept of range for Packet matching terms was initially proposed in
> classification and was removed since most HW implement packet classifier
> using TCAM and TCAMs only support matching and mask.
>
> The range can be configured using the existing PMR by intelligently
> configuring the system by using bit mask parameters in PMR.
>
> Let us take a simple example:
> PMR1 -- Term value = 0x and mask 0x00FF
> PMR2 -- Term value = 0x0100 and mask 0x01FF
> PMR3 -- Term value = 0x0200 and mask 0x02FF
>
> PMR1 will match all packet with the length range 0 to 255 bytes
> PMR2 will match all packets with the length range 256 to 511 bytes
> PMR3 will match all packets with the length range 512 to 767 bytes
>
> And the default CoS will receive all the remaining packets with higher
> lengths.
>
> Regards,
> Bala
>
> On 3 March 2016 at 09:11, huanggaoyang  wrote:
>
>> Hi,
>> Thank you for your explaining. But I can't totally agree with you.
>> I don't know how does the ODP_PMR_LEN support range match.
>> I mean if I want the packets with different lenth alloced from Pool No1~4
>> like this:
>>   lenthalloc from
>> (0, 200)Pool-No.1
>> [200, 800)Pool-No.2
>> [800, 1600)  Pool-No.3
>> other  Pool-No.4
>> How can I create  pair to implement this?
>>
>>
>> 在 2016/3/1 23:27, Bala Manoharan 写道:
>>
>> Hi,
>>
>> The above described use-case is implementable with the existing ODP
>> classification framework.
>>
>> Few points to take note for implementing this use-case
>> * Each CoS has an associated pool from which packets arriving at this CoS
>> is allocated.
>> * There is an existing PMR rule ODP_PMR_LEN which selects packets based
>> on the total length of received packets.
>>
>> example:
>> An application can create different PMR rules with term ODP_PMR_LEN each
>> associated with different CoSs. When packets of different length arrive at
>> the pktio interface they will be associated to their respective CoS based
>> on the PMR rules (in this case ODP_PMR_LEN). Since each CoS has an
>> associated pool then these packets which have been differentiated based on
>> their length will be allocated on the pool associated with the CoS.
>>
>> Hope this Helps,
>> Bala
>>
>> On 29 February 2016 at 15:58, huanggaoyang < 
>> huanggaoya...@huawei.com> wrote:
>>
>>> Make the packet IO interface support multi packet pools with different
>>> buffer size.
>>> When receiving packets, the pktio will alloc packets from the most
>>> suitable pool via packet len.
>>>
>>> It aims to save the memory in case that the Memory Resource is limited,
>>> and the pktio
>>> shoul

Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from multiple queues with tmo

[Bala Manoharan]

On 4 March 2016 at 15:21, Petri Savolainen 
wrote:

> Added odp_pktin_recv_mq_tmo() which allows application to
> poll multiple input queues (interfaces) with single call.
> The call includes timeout parameter which allows thread to
> e.g. sleep while waiting for more packets to arrive and thus
> avoid 100% CPU utilization when packet rate is low.
>
> Signed-off-by: Petri Savolainen 
> Signed-off-by: Juha-Matti Tilli 
> ---
>  include/odp/api/spec/packet_io.h   | 55
> ++
>  .../include/odp/api/plat/packet_io_types.h |  3 ++
>  2 files changed, 58 insertions(+)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 302d431..0932cf0 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -63,6 +63,15 @@ extern "C" {
>   * Actual MAC address sizes may be different.
>   */
>
> +/**
> + * @def ODP_PKTIN_NO_WAIT
> + * Do not wait on packet input
> + */
> +
> +/**
> + * @def ODP_PKTIN_WAIT
> + * Wait infinitely on packet input
> + */
>
>  /**
>   * Packet input mode
> @@ -530,6 +539,52 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  int odp_pktin_recv(odp_pktin_queue_t queue, odp_packet_t packets[], int
> num);
>
>  /**
> + * Receive packets directly from multiple interface input queues
> + *
> + * Receives up to 'num' packets from one of the specified pktio interface
> input
> + * queues. The index of the source queue is stored into 'from' output
> + * parameter. If there are no packets available on any of the queues,
> waits for
> + * packets depeding on 'wait' parameter value. Returns the number of
> packets
> + * received.
>

A Minor query, since there are more than one input queue and 'num' packets
are returned from only one of the input queue what happens when more than
one input queue contains the packet? Is there any inherent priority order
to be maintained by the implementation? Correct me if I am wrong but these
input queues are created based on hash parameters and does not contain any
priority value.

Regards,
Bala

> + *
> + * When an input queue has been configured with 'op_mode' value
> + * ODP_PKTIO_OP_MT_UNSAFE, the operation is optimized for single thread
> + * operation and the same queue must not be accessed simultaneously from
> + * multiple threads.
> + *
> + * @param  queues[]   Packet input queue handles for receiving packets
> + * @param  num_q  Number of input queues
> + * @param[out] from   Pointer for output of the source queue index.
> Ignored
> + *when NULL.
> + * @param[out] packets[]  Packet handle array for output of received
> packets
> + * @param  numMaximum number of packets to receive
> + * @param  wait   Wait time specified as as follows:
> + ** ODP_PKTIN_NO_WAIT: Do not wait
> + ** ODP_PKTIN_WAIT:Wait infinitely
> + ** Other values specify the minimum time to wait.
> + *  Use odp_pktin_wait_time() to convert
> nanoseconds
> + *  to a valid parameter value. Wait time may be
> + *  rounded up a small, platform specific amount.
> + *
> + * @return Number of packets received
> + * @retval <0 on failure
> + */
> +int odp_pktin_recv_mq_tmo(const odp_pktin_queue_t queues[], unsigned
> num_q,
> + unsigned *from, odp_packet_t packets[], int num,
> + uint64_t wait);
> +
> +/**
> + * Packet input wait time
> + *
> + * Converts nanoseconds to wait time values for packet input functions.
> + *
> + * @param nsec   Minimum number of nanoseconds to wait
> + *
> + * @return Wait parameter value for packet input functions
> + */
> +uint64_t odp_pktin_wait_time(uint64_t nsec);
> +
> +/**
>   * Send packets directly to an interface output queue
>   *
>   * Sends out a number of packets to the interface output queue. When
> diff --git a/platform/linux-generic/include/odp/api/plat/packet_io_types.h
> b/platform/linux-generic/include/odp/api/plat/packet_io_types.h
> index cd43083..5a45321 100644
> --- a/platform/linux-generic/include/odp/api/plat/packet_io_types.h
> +++ b/platform/linux-generic/include/odp/api/plat/packet_io_types.h
> @@ -44,6 +44,9 @@ typedef struct odp_pktout_queue_t {
>
>  #define ODP_PKTIO_MACADDR_MAXSIZE 16
>
> +#define ODP_PKTIN_NO_WAIT 0
> +#define ODP_PKTIN_WAITUINT64_MAX
> +
>  /** Get printable format of odp_pktio_t */
>  static inline uint64_t odp_pktio_to_u64(odp_pktio_t hdl)
>  {
> --
> 2.7.2
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from multiple queues with tmo

[Bala Manoharan]

On 4 March 2016 at 17:47, Tilli, Juha-Matti (Nokia - FI/Espoo) <
juha-matti.ti...@nokia.com> wrote:

> Hi,
>
>
>
> The current algorithm indeed is unfair, because queue 0 has the highest
> priority. There are at least two solutions to this:
>
> 1. Leave the priority order unspecified
>
> 2. Specify that queues are checked in the order they appear in the array
>
>
>
> I kind of like solution (2), because it allows the application to behave
> in a round-robin manner by altering the order of the queues between the
> calls:
>
> - odp_pktin_recv_mq_tmo({q1, q2, q3, q4}, …)
>
> - odp_pktin_recv_mq_tmo({q2, q3, q4, q1}, …)
>
> - odp_pktin_recv_mq_tmo({q3, q4, q1, q2}, …)
>
> - odp_pktin_recv_mq_tmo({q4, q1, q2, q3}, …)
>
> …
>
>
>
> Then essentially the priority of all queues averages out to have
> approximately the same average priority.
>
>
>
> So, you should perhaps consider in the API spec that the priority order
> could be defined to be 0, 1, 2, …. I cannot foresee any implementation
> which would use a different priority order.
>

Agreed. We can improve the documentation to specify that priority is in the
order of input queue in the array with '0' being highest priority.

Regards,
Bala

>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *EXT
> Savolainen, Petri (Nokia - FI/Espoo)
> *Sent:* Friday, March 04, 2016 12:46 PM
> *To:* EXT Bala Manoharan
> *Cc:* LNG ODP Mailman List
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from
> multiple queues with tmo
>
>
>
>
>
>
>
> *From:* EXT Bala Manoharan [mailto:bala.manoha...@linaro.org
> ]
> *Sent:* Friday, March 04, 2016 12:16 PM
> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from
> multiple queues with tmo
>
>
>
>
>
>
>
> On 4 March 2016 at 15:21, Petri Savolainen 
> wrote:
>
> Added odp_pktin_recv_mq_tmo() which allows application to
> poll multiple input queues (interfaces) with single call.
> The call includes timeout parameter which allows thread to
> e.g. sleep while waiting for more packets to arrive and thus
> avoid 100% CPU utilization when packet rate is low.
>
> Signed-off-by: Petri Savolainen 
> Signed-off-by: Juha-Matti Tilli 
> ---
>  include/odp/api/spec/packet_io.h   | 55
> ++
>  .../include/odp/api/plat/packet_io_types.h |  3 ++
>  2 files changed, 58 insertions(+)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 302d431..0932cf0 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -63,6 +63,15 @@ extern "C" {
>   * Actual MAC address sizes may be different.
>   */
>
> +/**
> + * @def ODP_PKTIN_NO_WAIT
> + * Do not wait on packet input
> + */
> +
> +/**
> + * @def ODP_PKTIN_WAIT
> + * Wait infinitely on packet input
> + */
>
>  /**
>   * Packet input mode
> @@ -530,6 +539,52 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  int odp_pktin_recv(odp_pktin_queue_t queue, odp_packet_t packets[], int
> num);
>
>  /**
> + * Receive packets directly from multiple interface input queues
> + *
> + * Receives up to 'num' packets from one of the specified pktio interface
> input
> + * queues. The index of the source queue is stored into 'from' output
> + * parameter. If there are no packets available on any of the queues,
> waits for
> + * packets depeding on 'wait' parameter value. Returns the number of
> packets
> + * received.
>
>
>
> A Minor query, since there are more than one input queue and 'num' packets
> are returned from only one of the input queue what happens when more than
> one input queue contains the packet? Is there any inherent priority order
> to be maintained by the implementation? Correct me if I am wrong but these
> input queues are created based on hash parameters and does not contain any
> priority value.
>
> Regards,
>
> Bala
>
>
>
> No priority order. We could say that queue[0] is checked always first,
> etc. But I think we can leave it implementation specific in which order
> queues are checked (at least for now). Application can use the plain recv()
> in between of these calls to poll “high” priority queues more of than the
> others.
>
>
>
> -Petri
>
>
>
>
>
>
>
>
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/2] linux-generic: packet_flags: use accessors to modify eth and l2 flag

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

Regards,
Bala

On 11 March 2016 at 14:03, Zoltan Kiss  wrote:

> Ping
>
> On 03/03/16 03:05, Zoltan Kiss wrote:
>
>> This makes it possible for other implementations like ODP-DPDK to reuse
>> classification code while using a different packet API.
>>
>> Signed-off-by: Zoltan Kiss 
>> ---
>>   platform/linux-generic/include/odp_classification_inlines.h |  2 +-
>>   platform/linux-generic/include/odp_packet_internal.h| 10
>> ++
>>   platform/linux-generic/odp_classification.c |  4 ++--
>>   3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_classification_inlines.h
>> b/platform/linux-generic/include/odp_classification_inlines.h
>> index 96cf77e..2318349 100644
>> --- a/platform/linux-generic/include/odp_classification_inlines.h
>> +++ b/platform/linux-generic/include/odp_classification_inlines.h
>> @@ -162,7 +162,7 @@ static inline int verify_pmr_dmac(const uint8_t
>> *pkt_addr,
>> uint64_t dmac_be = 0;
>> const odph_ethhdr_t *eth;
>>   - if (!pkt_hdr->input_flags.eth)
>> +   if (!odp_packet_hdr_has_eth(pkt_hdr))
>> return 0;
>> eth = (const odph_ethhdr_t *)(pkt_addr + pkt_hdr->l2_offset);
>> diff --git a/platform/linux-generic/include/odp_packet_internal.h
>> b/platform/linux-generic/include/odp_packet_internal.h
>> index 85d4924..d9fe544 100644
>> --- a/platform/linux-generic/include/odp_packet_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_internal.h
>> @@ -258,6 +258,16 @@ odp_buffer_t _odp_packet_to_buffer(odp_packet_t pkt);
>>   /* Convert a buffer handle to a packet handle */
>>   odp_packet_t _odp_packet_from_buffer(odp_buffer_t buf);
>>   +static inline int odp_packet_hdr_has_l2(odp_packet_hdr_t *pkt_hdr)
>> +{
>> +   return pkt_hdr->input_flags.l2;
>> +}
>> +
>> +static inline int odp_packet_hdr_has_eth(odp_packet_hdr_t *pkt_hdr)
>> +{
>> +   return pkt_hdr->input_flags.eth;
>> +}
>> +
>>   int _odp_parse_common(odp_packet_hdr_t *pkt_hdr, const uint8_t
>> *parseptr);
>> int _odp_cls_parse(odp_packet_hdr_t *pkt_hdr, const uint8_t
>> *parseptr);
>> diff --git a/platform/linux-generic/odp_classification.c
>> b/platform/linux-generic/odp_classification.c
>> index da195ad..4551951 100644
>> --- a/platform/linux-generic/odp_classification.c
>> +++ b/platform/linux-generic/odp_classification.c
>> @@ -1003,8 +1003,8 @@ cos_t *match_qos_l2_cos(pmr_l2_cos_t *l2_cos, const
>> uint8_t *pkt_addr,
>> const odph_vlanhdr_t *vlan;
>> uint16_t qos;
>>   - if (hdr->input_flags.l2 && hdr->input_flags.vlan &&
>> -   hdr->input_flags.eth) {
>> +   if (odp_packet_hdr_has_l2(hdr) && hdr->input_flags.vlan &&
>> +   odp_packet_hdr_has_eth(hdr)) {
>> eth = (const odph_ethhdr_t *)(pkt_addr + hdr->l2_offset);
>> vlan = (const odph_vlanhdr_t *)(ð->type);
>> qos = odp_be_to_cpu_16(vlan->tci);
>>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] linux-generic: dpdk: add packet classification support

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

On 18 March 2016 at 14:02, Elo, Matias (Nokia - FI/Espoo) <
matias@nokia.com> wrote:

> Ping.
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> EXT Matias
> > Elo
> > Sent: Friday, March 11, 2016 2:48 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCH] linux-generic: dpdk: add packet
> classification support
> >
> > Add packet classification support using _odp_packet_cls_enq
> > helper function.
> >
> > Signed-off-by: Matias Elo 
> > ---
> >  platform/linux-generic/pktio/dpdk.c | 54
> +--
> > --
> >  1 file changed, 31 insertions(+), 23 deletions(-)
> >
> > diff --git a/platform/linux-generic/pktio/dpdk.c b/platform/linux-
> > generic/pktio/dpdk.c
> > index a39e7dc..3b65d97 100644
> > --- a/platform/linux-generic/pktio/dpdk.c
> > +++ b/platform/linux-generic/pktio/dpdk.c
> > @@ -554,6 +554,7 @@ static inline int mbuf_to_pkt(pktio_entry_t
> *pktio_entry,
> >   struct rte_mbuf *mbuf;
> >   void *buf;
> >   int i, j;
> > + int nb_pkts = 0;
> >
> >   for (i = 0; i < num; i++) {
> >   mbuf = mbuf_table[i];
> > @@ -567,37 +568,44 @@ static inline int mbuf_to_pkt(pktio_entry_t
> > *pktio_entry,
> >
> >   pkt_len = rte_pktmbuf_pkt_len(mbuf);
> >
> > - pkt = packet_alloc(pktio_entry->s.pkt_dpdk.pool, pkt_len,
> 1);
> > - if (pkt == ODP_PACKET_INVALID) {
> > - ODP_ERR("packet_alloc failed\n");
> > - goto fail;
> > - }
> > + if (pktio_cls_enabled(pktio_entry)) {
> > + if (_odp_packet_cls_enq(pktio_entry,
> > + (const uint8_t *)buf,
> pkt_len,
> > + &pkt_table[nb_pkts]))
> > + nb_pkts++;
> > + } else {
> > + pkt = packet_alloc(pktio_entry->s.pkt_dpdk.pool,
> > +pkt_len, 1);
> > + if (pkt == ODP_PACKET_INVALID) {
> > + ODP_ERR("packet_alloc failed\n");
> > + goto fail;
> > + }
> >
> > - pkt_hdr = odp_packet_hdr(pkt);
> > + pkt_hdr = odp_packet_hdr(pkt);
> >
> > - /* For now copy the data in the mbuf,
> > -worry about zero-copy later */
> > - if (odp_packet_copydata_in(pkt, 0, pkt_len, buf) != 0) {
> > - ODP_ERR("odp_packet_copydata_in failed\n");
> > - odp_packet_free(pkt);
> > - goto fail;
> > - }
> > + /* For now copy the data in the mbuf,
> > +worry about zero-copy later */
> > + if (odp_packet_copydata_in(pkt, 0, pkt_len, buf)
> != 0) {
> > + ODP_ERR("odp_packet_copydata_in failed\n");
> > + odp_packet_free(pkt);
> > + goto fail;
> > + }
> >
> > - packet_parse_l2(pkt_hdr);
> > + packet_parse_l2(pkt_hdr);
> >
> > - pkt_hdr->input = pktio_entry->s.handle;
> > + pkt_hdr->input = pktio_entry->s.handle;
> >
> > - if (mbuf->ol_flags & PKT_RX_RSS_HASH) {
> > - pkt_hdr->has_hash = 1;
> > - pkt_hdr->flow_hash = mbuf->hash.rss;
> > - }
> > -
> > - pkt_table[i] = pkt;
> > + if (mbuf->ol_flags & PKT_RX_RSS_HASH) {
> > + pkt_hdr->has_hash = 1;
> > + pkt_hdr->flow_hash = mbuf->hash.rss;
> > + }
> >
> > + pkt_table[nb_pkts++] = pkt;
> > + }
> >   rte_pktmbuf_free(mbuf);
> >   }
> >
> > - return i;
> > + return nb_pkts;
> >
> >  fail:
> >   ODP_ERR("Creating ODP packet failed\n");
> > @@ -653,7 +661,7 @@ static int dpdk_recv_queue(pktio_entry_t
> *pktio_entry,
> >  {
> >   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
> >   pkt_cache_t *rx_cache = &pkt_dpdk->rx_cache[index];
> > - uint16_t nb_rx;
> > + int nb_rx;
> >   struct rte_mbuf *rx_mbufs[num];
> >   int i;
> >   unsigned cache_idx;
> > --
> > 1.9.1
> >
> > ___
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/lng-odp
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH] api: pktio: add odp_pktin_recv_tmo

[Bala Manoharan]

On 17 March 2016 at 21:09, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Usage and implementation are simpler without the wait parameter. I think
> it’s better to keep these two versions separate: one that never calls any
> system calls, and one that may use system calls to check time and sleep.
> The no_wait option is handy if application needs to swap between wait X
> nsec and no_wait.
>
>
I was thinking more like adding wait parameter to odp_pktio_recv() function
and removing odp_pktio_recv_tmo() so that if the wait parameter is
ODP_PKTIN_NO_WAIT there is no need for any system call from the
implementation.
Basically this reduces the total number of APIs in the ODP and also the
usage of the API is much cleaner since in the proposed case both
odp_pktin_recv_tmo() and odp_pktin_recv() function have the same
description except for timeout.

Regards,
Bala

>
>
> -Petri
>
>
>
>
>
> *From:* EXT Bala Manoharan [mailto:bala.manoha...@linaro.org]
> *Sent:* Thursday, March 17, 2016 4:32 PM
> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH] api: pktio: add
> odp_pktin_recv_tmo
>
>
>
> Hi,
>
>
>
> odp_pktin_recv_tmo() function called with wait value equal
> to ODP_PKTIN_NO_WAIT is similar to odp_pktin_recv() function. Hence why
> cant we simply merge these two functions as a single one. odp_pktin_recv()
> functions looks redundant.
>
>
> Regards,
> Bala
>
>
>
> On 17 March 2016 at 19:37, Petri Savolainen 
> wrote:
>
> Added single queue recv function with timeout. In a simple
> configuration each thread polls a single input queue. Timeout
> version of single queue receive allows thread to sleep when
> there are no packets. odp_pktin_recv_mq_tmo would be unnecessary
> complex to use for single input queue.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/packet_io.h   | 36 ++---
>  platform/linux-generic/odp_packet_io.c | 49
> +-
>  2 files changed, 81 insertions(+), 4 deletions(-)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 6fe2cac..1860b31 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -522,8 +522,10 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  /**
>   * Receive packets directly from an interface input queue
>   *
> - * Receives up to 'num' packets from the pktio interface input queue. When
> - * input queue parameter 'op_mode' has been set to ODP_PKTIO_OP_MT_UNSAFE,
> + * Receives up to 'num' packets from the pktio interface input queue.
> Returns
> + * the number of packets received.
> + *
> + * When input queue parameter 'op_mode' has been set to
> ODP_PKTIO_OP_MT_UNSAFE,
>   * the operation is optimized for single thread operation per queue and
> the same
>   * queue must not be accessed simultaneously from multiple threads.
>   *
> @@ -539,7 +541,35 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  int odp_pktin_recv(odp_pktin_queue_t queue, odp_packet_t packets[], int
> num);
>
>  /**
> - * Receive packets directly from multiple interface input queues
> + * Receive packets directly from an interface input queue with timeout
> + *
> + * Receives up to 'num' packets from the pktio interface input queue. If
> there
> + * are no packets available, waits for packets depeding on 'wait'
> parameter
> + * value. Returns the number of packets received.
> + *
> + * When input queue parameter 'op_mode' has been set to
> ODP_PKTIO_OP_MT_UNSAFE,
> + * the operation is optimized for single thread operation per queue and
> the same
> + * queue must not be accessed simultaneously from multiple threads.
> + *
> + * @param  queue  Packet input queue handle for receiving packets
> + * @param[out] packets[]  Packet handle array for output of received
> packets
> + * @param  numMaximum number of packets to receive
> + * @param  wait   Wait time specified as as follows:
> + ** ODP_PKTIN_NO_WAIT: Do not wait
> + ** ODP_PKTIN_WAIT:Wait infinitely
> + ** Other values specify the minimum time to wait.
> + *  Use odp_pktin_wait_time() to convert
> nanoseconds
> + *  to a valid parameter value. Wait time may be
> + *  rounded up a small, platform specific amount.
> + *
> + * @return Number of packets received
> + * @retval <0 on failure
> + */
> +int odp_pktin_recv_

Re: [lng-odp] [PATCHv3] linux-generic:release memory during session destory

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

On 15 March 2016 at 18:39, balakrishna.garapati <
balakrishna.garap...@linaro.org> wrote:

> Signed-off-by: balakrishna.garapati 
> ---
>  platform/linux-generic/odp_crypto.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/platform/linux-generic/odp_crypto.c
> b/platform/linux-generic/odp_crypto.c
> index 08b479d..e468677 100644
> --- a/platform/linux-generic/odp_crypto.c
> +++ b/platform/linux-generic/odp_crypto.c
> @@ -704,6 +704,8 @@ int odp_crypto_session_destroy(odp_crypto_session_t
> session)
> odp_crypto_generic_session_t *generic;
>
> generic = (odp_crypto_generic_session_t *)(intptr_t)session;
> +if (generic->cipher.alg == ODP_CIPHER_ALG_AES128_GCM)
> +   EVP_CIPHER_CTX_free(generic->cipher.data.aes_gcm.ctx);
> memset(generic, 0, sizeof(*generic));
> free_session(generic);
> return 0;
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH] api: pktio: add odp_pktin_recv_tmo

[Bala Manoharan]

Hi,

odp_pktin_recv_tmo() function called with wait value equal to ODP_PKTIN_NO_WAIT
is similar to odp_pktin_recv() function. Hence why cant we simply merge
these two functions as a single one. odp_pktin_recv() functions looks
redundant.

Regards,
Bala

On 17 March 2016 at 19:37, Petri Savolainen 
wrote:

> Added single queue recv function with timeout. In a simple
> configuration each thread polls a single input queue. Timeout
> version of single queue receive allows thread to sleep when
> there are no packets. odp_pktin_recv_mq_tmo would be unnecessary
> complex to use for single input queue.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/packet_io.h   | 36 ++---
>  platform/linux-generic/odp_packet_io.c | 49
> +-
>  2 files changed, 81 insertions(+), 4 deletions(-)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 6fe2cac..1860b31 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -522,8 +522,10 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  /**
>   * Receive packets directly from an interface input queue
>   *
> - * Receives up to 'num' packets from the pktio interface input queue. When
> - * input queue parameter 'op_mode' has been set to ODP_PKTIO_OP_MT_UNSAFE,
> + * Receives up to 'num' packets from the pktio interface input queue.
> Returns
> + * the number of packets received.
> + *
> + * When input queue parameter 'op_mode' has been set to
> ODP_PKTIO_OP_MT_UNSAFE,
>   * the operation is optimized for single thread operation per queue and
> the same
>   * queue must not be accessed simultaneously from multiple threads.
>   *
> @@ -539,7 +541,35 @@ odp_pktio_t odp_pktio_lookup(const char *name);
>  int odp_pktin_recv(odp_pktin_queue_t queue, odp_packet_t packets[], int
> num);
>
>  /**
> - * Receive packets directly from multiple interface input queues
> + * Receive packets directly from an interface input queue with timeout
> + *
> + * Receives up to 'num' packets from the pktio interface input queue. If
> there
> + * are no packets available, waits for packets depeding on 'wait'
> parameter
> + * value. Returns the number of packets received.
> + *
> + * When input queue parameter 'op_mode' has been set to
> ODP_PKTIO_OP_MT_UNSAFE,
> + * the operation is optimized for single thread operation per queue and
> the same
> + * queue must not be accessed simultaneously from multiple threads.
> + *
> + * @param  queue  Packet input queue handle for receiving packets
> + * @param[out] packets[]  Packet handle array for output of received
> packets
> + * @param  numMaximum number of packets to receive
> + * @param  wait   Wait time specified as as follows:
> + ** ODP_PKTIN_NO_WAIT: Do not wait
> + ** ODP_PKTIN_WAIT:Wait infinitely
> + ** Other values specify the minimum time to wait.
> + *  Use odp_pktin_wait_time() to convert
> nanoseconds
> + *  to a valid parameter value. Wait time may be
> + *  rounded up a small, platform specific amount.
> + *
> + * @return Number of packets received
> + * @retval <0 on failure
> + */
> +int odp_pktin_recv_tmo(odp_pktin_queue_t queue, odp_packet_t packets[],
> +  int num, uint64_t wait);
> +
> +/**
> + * Receive packets directly from multiple interface input queues with
> timeout
>   *
>   * Receives up to 'num' packets from one of the specified pktio interface
> input
>   * queues. The index of the source queue is stored into 'from' output
> diff --git a/platform/linux-generic/odp_packet_io.c
> b/platform/linux-generic/odp_packet_io.c
> index aafb3d9..948baa8 100644
> --- a/platform/linux-generic/odp_packet_io.c
> +++ b/platform/linux-generic/odp_packet_io.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -28,7 +29,12 @@
>  #include 
>  #include 
>
> -#define SLEEP_NSEC 1000
> +/* Sleep this many nanoseconds between pktin receive calls */
> +#define SLEEP_NSEC  1000
> +
> +/* Check total sleep time about every SLEEP_CHECK * SLEEP_NSEC
> nanoseconds.
> + * Must be power of two. */
> +#define SLEEP_CHECK 32
>
>  pktio_table_t *pktio_tbl;
>
> @@ -1387,6 +1393,47 @@ int odp_pktin_recv(odp_pktin_queue_t queue,
> odp_packet_t packets[], int num)
> return single_recv_queue(entry, queue.index, packets, num);
>  }
>
> +int odp_pktin_recv_tmo(odp_pktin_queue_t queue, odp_packet_t packets[],
> int num,
> +  uint64_t wait)
> +{
> +   int ret;
> +   odp_time_t t1, t2;
> +   struct timespec ts;
> +
> +   if (wait != ODP_PKTIN_WAIT) {
> +   ts.tv_sec  = 0;
> +   ts.tv_nsec = SLEEP_NSEC;
> +
> +   t1 = odp_time_sum(odp_time_local(),
> + odp_time_local_fr

Re: [lng-odp] [PATCH] linux-generic: tm: reduce byte range to prevent array overflow

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

Regards,
Bala

On 27 March 2016 at 01:57, Bill Fischofer  wrote:

> Resolve bug https://bugs.linaro.org/show_bug.cgi?id=2120 by reducing
> the random array guard by one to ensure that at least two bytes of random
> data remain before accessing them.
>
> Signed-off-by: Bill Fischofer 
> ---
>  platform/linux-generic/odp_traffic_mngr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/platform/linux-generic/odp_traffic_mngr.c
> b/platform/linux-generic/odp_traffic_mngr.c
> index 99dc020..08e83c1 100644
> --- a/platform/linux-generic/odp_traffic_mngr.c
> +++ b/platform/linux-generic/odp_traffic_mngr.c
> @@ -154,7 +154,7 @@ static uint16_t tm_random16(tm_random_data_t
> *tm_random_data)
> uint32_t buf_idx;
> uint16_t rand8a, rand8b;
>
> -   if (256 <= tm_random_data->next_random_byte)
> +   if (255 <= tm_random_data->next_random_byte)
> tm_init_random_data(tm_random_data);
>
> /* Collect 2 random bytes and return them.  Endianness does NOT
> matter
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 4/6] api: pktio: add classifier enable pktin_queue_param

[Bala Manoharan]

On 24 March 2016 at 20:19, Petri Savolainen 
wrote:

> Added explicit classifier enable option for pktin event
> queues. Hashing and classification cannot be enabled at the
> same time. Pktin_queue_config may create target queues for
> classification or application may create those later.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/packet_io.h | 40
> ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 6af1ebb..767a1b2 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -161,25 +161,45 @@ typedef struct odp_pktin_queue_param_t {
>   * applicable. */
> odp_pktio_op_mode_t op_mode;
>
> +   /** Enable classifier
> + *
> + * * 0: Classifier is disabled (default)
> + * * 1: Classifier is enabled. Use classifier instead of flow
> hashing
> + *  to direct incoming packets into pktin event queues.
> Classifier
> + *  can be enabled only in ODP_PKTIN_MODE_SCHED and
> + *  ODP_PKTIN_MODE_QUEUE modes. */
> +   odp_bool_t classifier_enable;
> +
> /** Enable flow hashing
> - * 0: Do not hash flows
> - * 1: Hash flows to input queues */
> + *
> + * * 0: Do not hash flows (default)
> + * * 1: Enable flow hashing. Use flow hashing instead of
> classifier to
> + *  spread incoming packets into input queues. Hashing can be
> + *  enabled in all modes. */
> odp_bool_t hash_enable;
>

IMO, a short description can be added stating that both 'hash_enable' and
'classifier_enable' can NOT be true at the same time and that only one of
the two values can be true.

Regards,
Bala

>
> -   /** Protocol field selection for hashing. Multiple protocols can be
> - * selected. */
> +   /** Protocol field selection for hashing
> + *
> + * Multiple protocols can be selected. Ignored when 'hash_enable'
> is
> + * zero. The default value is all bits zero. */
> odp_pktin_hash_proto_t hash_proto;
>
> -   /** Number of input queues to be created. More than one input queue
> - * require input hashing or classifier setup. Hash_proto is
> ignored
> - * when hash_enable is zero or num_queues is one. This value must
> be
> - * between 1 and interface capability. Queue type is defined by
> the
> +   /** Number of input queues to be created
> + *
> + * When classifier is enabled the number of queues may be zero
> + * (in odp_pktin_queue_config() step), otherwise at least one
> + * queue is required. More than one input queues require either
> flow
> + * hashing or classifier enabled. The maximum value is defined by
> + * pktio capability 'max_input_queues'. Queue type is defined by
> the
>   * input mode. The default value is 1. */
> unsigned num_queues;
>
> -   /** Queue parameters for creating input queues in
> ODP_PKTIN_MODE_QUEUE
> +   /** Queue parameters
> + *
> + * These are used for input queue creation in ODP_PKTIN_MODE_QUEUE
>   * or ODP_PKTIN_MODE_SCHED modes. Scheduler parameters are
> considered
> - * only in ODP_PKTIN_MODE_SCHED mode. */
> + * only in ODP_PKTIN_MODE_SCHED mode. Default values are defined
> in
> + * odp_queue_param_t documentation. */
> odp_queue_param_t queue_param;
>
>  } odp_pktin_queue_param_t;
> --
> 2.7.2
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 5/6] api: pktio: add checksum offload options

[Bala Manoharan]

Regards,
Bala

On 24 March 2016 at 20:19, Petri Savolainen 
wrote:

> Added options for selecting IP/UDP/TCP/SCTP checksum offload on
> packet input and output. Packets with input checksum failure are
> either dropped or reported with packet_has_l3/l4_error flags.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/packet_io.h | 66
> +++-
>  1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 767a1b2..f9df7c3 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -246,7 +246,9 @@ typedef struct odp_pktio_param_t {
>  /**
>   * Packet input configuration options bit field
>   *
> - * Packet input configuration options listed in a bit field structure.
> + * Packet input configuration options listed in a bit field structure.
> Depending
> + * on configuration erroneous packets are either dropped or marked with
> error
> + * flags (see e.g. odp_packet_has_error() and odp_packet_has_l3_error()).
>   */
>  typedef union odp_pktin_config_opt_t {
> /** Option flags */
> @@ -257,6 +259,34 @@ typedef union odp_pktin_config_opt_t {
> /** Timestamp (at least) IEEE1588 / PTP packets
>   * on packet input */
> uint64_t ts_ptp: 1;
> +
> +   /** Check IPv4 header checksum on packet input */
> +   uint64_t ipv4_chksum   : 1;
> +
> +   /** Check UDP checksum on packet input */
> +   uint64_t udp_chksum: 1;
> +
> +   /** Check TCP checksum on packet input */
> +   uint64_t tcp_chksum: 1;
> +
> +   /** Check SCTP checksum on packet input */
> +   uint64_t sctp_chksum   : 1;
> +
> +   /** Drop packets with an IPv4 error on packet input */
> +   uint64_t drop_ipv4_err : 1;
> +
> +   /** Drop packets with an IPv6 error on packet input */
> +   uint64_t drop_ipv6_err : 1;
> +
> +   /** Drop packets with a UDP error on packet input */
> +   uint64_t drop_udp_err  : 1;
> +
> +   /** Drop packets with a TCP error on packet input */
> +   uint64_t drop_tcp_err  : 1;
> +
> +   /** Drop packets with a SCTP error on packet input */
> +   uint64_t drop_sctp_err : 1;
> +
>

We have an existing mechanism in classifier where the application can
configure an error CoS so that the packets with error are sent to
Error_CoS. So do we really need this mechanism at the interface level to
drop packets with error.

} bit;
>
> /** All bits of the bit field structure
> @@ -267,6 +297,35 @@ typedef union odp_pktin_config_opt_t {
>  } odp_pktin_config_opt_t;
>
>  /**
> + * Packet output configuration options bit field
> + *
> + * Packet output configuration options listed in a bit field structure.
> + */
> +typedef union odp_pktout_config_opt_t {
> +   /** Option flags */
> +   struct {
> +   /** Insert IPv4 header checksum on packet output */
> +   uint64_t ipv4_chksum  : 1;
> +
> +   /** Insert UDP checksum on packet output */
> +   uint64_t udp_chksum   : 1;
> +
> +   /** Insert TCP checksum on packet output */
> +   uint64_t tcp_chksum   : 1;
> +
> +   /** Insert SCTP checksum on packet output */
> +   uint64_t sctp_chksum  : 1;
> +
> +   } bit;
>

IMO, since L3/L4 checksum calculation is a per packet operation it might be
better to add this in packet meta data so that if the application does not
modify the packet then there is no need to re-calculate the L3/L4 checksum.
Hence if an application modifies a particular packet it can set the
checksum calculation bit on that packet and the implementation will
calculate and insert checksum for the specific packet before transmission.
By having this as a per-packet parameter there is no need to calculate
checksum for all packets in the interface.

> +
> +   /** All bits of the bit field structure
> + *
> + * This field can be used to set/clear all flags, or bitwise
> + * operations over the entire structure. */
> +   uint64_t all_bits;
> +} odp_pktout_config_opt_t;
> +
> +/**
>   * Packet IO configuration options
>   *
>   * Packet IO interface level configuration options. Use
> odp_pktio_capability()
> @@ -279,6 +338,11 @@ typedef struct odp_pktio_config_t {
>  *  Default value for all bits is zero. */
> odp_pktin_config_opt_t pktin;
>
> +   /** Packet output configuration options bit field
> +*
> +*  Default value for all bits is zero. */
> +   odp_pktout_config_opt_t pktout;
> +
>  } odp_pktio_config_t;
>
>  /**
> --
> 2.7.2
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org

Re: [lng-odp] [API-NEXT PATCH 5/6] api: pktio: add checksum offload options

[Bala Manoharan]

On 28 March 2016 at 19:14, Bill Fischofer  wrote:

>
>
> On Mon, Mar 28, 2016 at 5:25 AM, Bala Manoharan  > wrote:
>
>>
>>
>> Regards,
>> Bala
>>
>> On 24 March 2016 at 20:19, Petri Savolainen 
>> wrote:
>>
>>> Added options for selecting IP/UDP/TCP/SCTP checksum offload on
>>> packet input and output. Packets with input checksum failure are
>>> either dropped or reported with packet_has_l3/l4_error flags.
>>>
>>> Signed-off-by: Petri Savolainen 
>>> ---
>>>  include/odp/api/spec/packet_io.h | 66
>>> +++-
>>>  1 file changed, 65 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/odp/api/spec/packet_io.h
>>> b/include/odp/api/spec/packet_io.h
>>> index 767a1b2..f9df7c3 100644
>>> --- a/include/odp/api/spec/packet_io.h
>>> +++ b/include/odp/api/spec/packet_io.h
>>> @@ -246,7 +246,9 @@ typedef struct odp_pktio_param_t {
>>>  /**
>>>   * Packet input configuration options bit field
>>>   *
>>> - * Packet input configuration options listed in a bit field structure.
>>> + * Packet input configuration options listed in a bit field structure.
>>> Depending
>>> + * on configuration erroneous packets are either dropped or marked with
>>> error
>>> + * flags (see e.g. odp_packet_has_error() and
>>> odp_packet_has_l3_error()).
>>>   */
>>>  typedef union odp_pktin_config_opt_t {
>>> /** Option flags */
>>> @@ -257,6 +259,34 @@ typedef union odp_pktin_config_opt_t {
>>> /** Timestamp (at least) IEEE1588 / PTP packets
>>>   * on packet input */
>>> uint64_t ts_ptp: 1;
>>> +
>>> +   /** Check IPv4 header checksum on packet input */
>>> +   uint64_t ipv4_chksum   : 1;
>>> +
>>> +   /** Check UDP checksum on packet input */
>>> +   uint64_t udp_chksum: 1;
>>> +
>>> +   /** Check TCP checksum on packet input */
>>> +   uint64_t tcp_chksum: 1;
>>> +
>>> +   /** Check SCTP checksum on packet input */
>>> +   uint64_t sctp_chksum   : 1;
>>> +
>>> +   /** Drop packets with an IPv4 error on packet input */
>>> +   uint64_t drop_ipv4_err : 1;
>>> +
>>> +   /** Drop packets with an IPv6 error on packet input */
>>> +   uint64_t drop_ipv6_err : 1;
>>> +
>>> +   /** Drop packets with a UDP error on packet input */
>>> +   uint64_t drop_udp_err  : 1;
>>> +
>>> +   /** Drop packets with a TCP error on packet input */
>>> +   uint64_t drop_tcp_err  : 1;
>>> +
>>> +   /** Drop packets with a SCTP error on packet input */
>>> +   uint64_t drop_sctp_err : 1;
>>> +
>>>
>>
>> We have an existing mechanism in classifier where the application can
>> configure an error CoS so that the packets with error are sent to
>> Error_CoS. So do we really need this mechanism at the interface level to
>> drop packets with error.
>>
>> } bit;
>>>
>>> /** All bits of the bit field structure
>>> @@ -267,6 +297,35 @@ typedef union odp_pktin_config_opt_t {
>>>  } odp_pktin_config_opt_t;
>>>
>>>  /**
>>> + * Packet output configuration options bit field
>>> + *
>>> + * Packet output configuration options listed in a bit field structure.
>>> + */
>>> +typedef union odp_pktout_config_opt_t {
>>> +   /** Option flags */
>>> +   struct {
>>> +   /** Insert IPv4 header checksum on packet output */
>>> +   uint64_t ipv4_chksum  : 1;
>>> +
>>> +   /** Insert UDP checksum on packet output */
>>> +   uint64_t udp_chksum   : 1;
>>> +
>>> +   /** Insert TCP checksum on packet output */
>>> +   uint64_t tcp_chksum   : 1;
>>> +
>>> +   /** Insert SCTP checksum on packet output */
>>> +   uint64_t sctp_chksum  : 1;
>>> +
>>> +   } bit;
>>>
>>
>> IMO, since L3/L4 checksum calculation is a per packet operation it might
>> be better to add this in packet meta data so that if the application does
>> not modify the pa

Re: [lng-odp] [API-NEXT PATCH 4/6] api: pktio: add classifier enable pktin_queue_param

[Bala Manoharan]

On 29 March 2016 at 18:11, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>
>
>
> *From:* EXT Bala Manoharan [mailto:bala.manoha...@linaro.org]
> *Sent:* Monday, March 28, 2016 12:34 PM
> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 4/6] api: pktio: add classifier
> enable pktin_queue_param
>
>
>
>
>
> On 24 March 2016 at 20:19, Petri Savolainen 
> wrote:
>
> Added explicit classifier enable option for pktin event
> queues. Hashing and classification cannot be enabled at the
> same time. Pktin_queue_config may create target queues for
> classification or application may create those later.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/packet_io.h | 40
> ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/include/odp/api/spec/packet_io.h
> b/include/odp/api/spec/packet_io.h
> index 6af1ebb..767a1b2 100644
> --- a/include/odp/api/spec/packet_io.h
> +++ b/include/odp/api/spec/packet_io.h
> @@ -161,25 +161,45 @@ typedef struct odp_pktin_queue_param_t {
>   * applicable. */
> odp_pktio_op_mode_t op_mode;
>
> +   /** Enable classifier
> + *
> + * * 0: Classifier is disabled (default)
> + * * 1: Classifier is enabled. Use classifier instead of flow
> hashing
> + *  to direct incoming packets into pktin event queues.
> Classifier
> + *  can be enabled only in ODP_PKTIN_MODE_SCHED and
> + *  ODP_PKTIN_MODE_QUEUE modes. */
> +   odp_bool_t classifier_enable;
> +
> /** Enable flow hashing
> - * 0: Do not hash flows
> - * 1: Hash flows to input queues */
> + *
> + * * 0: Do not hash flows (default)
> + * * 1: Enable flow hashing. Use flow hashing instead of
> classifier to
> + *  spread incoming packets into input queues. Hashing can be
> + *  enabled in all modes. */
> odp_bool_t hash_enable;
>
>
>
> IMO, a short description can be added stating that both 'hash_enable' and
> 'classifier_enable' can NOT be true at the same time and that only one of
> the two values can be true.
>
>
>
> Regards,
>
> Bala
>
>
>
> It’s there already in the form of “X instead of Y”, but I can change it to
> be more explicit if needed.
>
>
>

IMO, it is better to be explicit to avoid any discrepancy.

Regards,
Bala

> -Petri
>
>
>
>
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 5/6] api: pktio: add checksum offload options

[Bala Manoharan]

On 30 March 2016 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>  /**
> + * Packet output configuration options bit field
> + *
> + * Packet output configuration options listed in a bit field structure.
> + */
> +typedef union odp_pktout_config_opt_t {
> +   /** Option flags */
> +   struct {
> +   /** Insert IPv4 header checksum on packet output */
> +   uint64_t ipv4_chksum  : 1;
> +
> +   /** Insert UDP checksum on packet output */
> +   uint64_t udp_chksum   : 1;
> +
> +   /** Insert TCP checksum on packet output */
> +   uint64_t tcp_chksum   : 1;
> +
> +   /** Insert SCTP checksum on packet output */
> +   uint64_t sctp_chksum  : 1;
> +
> +   } bit;
>
>
>
> IMO, since L3/L4 checksum calculation is a per packet operation it might
> be better to add this in packet meta data so that if the application does
> not modify the packet then there is no need to re-calculate the L3/L4
> checksum. Hence if an application modifies a particular packet it can set
> the checksum calculation bit on that packet and the implementation will
> calculate and insert checksum for the specific packet before transmission.
> By having this as a per-packet parameter there is no need to calculate
> checksum for all packets in the interface.
>
>
>
> That's a good point.  But I don't view these as exclusive.  It makes sense
> to enable/disable checksum offload at the interface level and then provide
> override capabilities on a per-packet basis so that only exceptional
> packets need additional attributes.
>
>
>
>
>
> I am really not sure if we need this parameter in two places usually the
> packets which require checksum recalculation are newly created packets and
> those which are modified by the application and it seems logical that
> whenever an application modifies the packet he just sets this checksum
> update flag and implementation does the rest.
>
> coz if we have this parameter in two places then for each packet which
> does not need checksum update the implementation should always check two
> parameters.
>
>
>
> Regards,
>
> Bala
>
>
>
> A single packet level param would require that all implementations are
> able to do all checksums (IPv4, UDP, TCP, SCTP, others in future)
> efficiently. With parameters in two levels, e.g. a switch application can
> inform implementation that it never needs any L3/L4 checksum offload (since
> it does not modify packet data), hence the implementation can e.g. shutdown
> NIC checksum capability or take a shorter code path in firmware and
> potentially provide a higher packet rate. An application terminating L4
> protocols would always need offload and thus enable the feature. An
> application that sometimes need offload would enable the feature, but mark
> packets that does not need offload. All combinations are possible, but if
> application mostly needs checksum it enables the feature and if it does not
> mostly need the feature disables it.
>
>
>
> Implementation may be done in many ways. If checksumming is disabled, all
> packets are marked (inside implementation) to not need checksum offload. If
> checksumming is enabled, all packets are marked to need checksum,
>  application would clear the mark with packet level checksum disable call.
> In both cases the packet output function could check only the packet level
> flag. The interface level enable/disable selection could even modify the
> code path (e.g. select different function pointer) so that the logic would
> be inversed and checksum not needed flag (e.g. default value 0) in packet
> descriptor would mean checksum needed, etc.
>
>
>
> -Petri
>
>
>

As discussed in the meeting, I have no further objection and we can go
ahead with the above changes. Maybe we can add the description given in
this mail to API for better clarity.

Regards,
Bala
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 2/2] linux-generic: classification: remove unused code

[Bala Manoharan]

For this patch alone:
Reviewed-by: Balasubramanian Manoharan 


On 8 April 2016 at 00:23, Zoltan Kiss  wrote:

> This function is not referred.
>
> Signed-off-by: Zoltan Kiss 
> ---
>  platform/linux-generic/include/odp_classification_internal.h |  9
> ++---
>  platform/linux-generic/odp_classification.c  | 10
> --
>  2 files changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/platform/linux-generic/include/odp_classification_internal.h
> b/platform/linux-generic/include/odp_classification_internal.h
> index 86b40fc..3a88462 100644
> --- a/platform/linux-generic/include/odp_classification_internal.h
> +++ b/platform/linux-generic/include/odp_classification_internal.h
> @@ -54,6 +54,8 @@ based on the l3_preference value of the pktio
>  cos_t *match_qos_cos(pktio_entry_t *entry, const uint8_t *pkt_addr,
>  odp_packet_hdr_t *hdr);
>  /**
> +@internal
> +
>  Packet Classifier
>
>  Start function for Packet Classifier
> @@ -61,13 +63,6 @@ This function calls Classifier module internal
> functions for a given packet and
>  enqueues the packet to specific Queue based on PMR and CoS selected.
>  The packet is allocated from the pool associated with the CoS
>  **/
> -int packet_classifier(odp_pktio_t pktio, odp_packet_t pkt);
> -
> -/**
> -@internal
> -
> -Same as packet classifier uses linux-generic internal pktio struct
> -**/
>  int _odp_packet_classifier(pktio_entry_t *entry, odp_packet_t pkt);
>
>  /**
> diff --git a/platform/linux-generic/odp_classification.c
> b/platform/linux-generic/odp_classification.c
> index 4f2974b..2ad190b 100644
> --- a/platform/linux-generic/odp_classification.c
> +++ b/platform/linux-generic/odp_classification.c
> @@ -774,16 +774,6 @@ int _odp_packet_classifier(pktio_entry_t *entry,
> odp_packet_t pkt)
> }
>  }
>
> -int packet_classifier(odp_pktio_t pktio, odp_packet_t pkt)
> -{
> -   pktio_entry_t *entry;
> -
> -   entry = get_pktio_entry(pktio);
> -   if (entry == NULL)
> -   return -1;
> -   return _odp_packet_classifier(entry, pkt);
> -}
> -
>  cos_t *pktio_select_cos(pktio_entry_t *entry, const uint8_t *pkt_addr,
> odp_packet_hdr_t *pkt_hdr)
>  {
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

Hi,

Comments inline...

Regards,
Bala

On 8 April 2016 at 00:23, Zoltan Kiss  wrote:

> The callers are only interested whether there is a CoS or not. It is not
> an error if there isn't, so it has a positive return value. Any other case
> needs to release the packet, which is not handled after calling
> queue_enq().
>
> Signed-off-by: Zoltan Kiss 
> ---
>  platform/linux-generic/odp_classification.c | 9 +++--
>  platform/linux-generic/pktio/loop.c | 2 +-
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/platform/linux-generic/odp_classification.c
> b/platform/linux-generic/odp_classification.c
> index f5e4673..4f2974b 100644
> --- a/platform/linux-generic/odp_classification.c
> +++ b/platform/linux-generic/odp_classification.c
> @@ -743,7 +743,7 @@ int _odp_packet_classifier(pktio_entry_t *entry,
> odp_packet_t pkt)
> /* Matching PMR and selecting the CoS for the packet*/
> cos = pktio_select_cos(entry, pkt_addr, pkt_hdr);
> if (cos == NULL)
> -   return -1;
> +   return 1;
>

The scenario of NULL Cos will occur only whether there is an invalid
configuration done by the application. If no other CoS matches the packet
then default CoS will be applied, this NULL will occur only if there is no
defaultCoS configured and hence it is better to return the error to the
calling function so that a proper action could be taken.


> if (cos->s.pool == NULL) {
> odp_packet_free(pkt);
> @@ -766,7 +766,12 @@ int _odp_packet_classifier(pktio_entry_t *entry,
> odp_packet_t pkt)
>
> /* Enqueuing the Packet based on the CoS */
> queue = cos->s.queue;
> -   return queue_enq(queue, odp_buf_to_hdr((odp_buffer_t)new_pkt), 0);
> +   if (queue_enq(queue, odp_buf_to_hdr((odp_buffer_t)new_pkt), 0)) {
> +   odp_packet_free(new_pkt);
> +   return -1;
> +   } else {
> +   return 0;
> +   }
>

IMO packets should be freed only by the receiving module rather than by the
classifier in this specific error. The classification module drops a packet
only on specific cases either on error CoS or when the packet pool is full.
The idea of returning an error value is that the caller function knows that
the packet is not enqueued and it has to either free the packet or check
the configuration.

You had mentioned that this patch is required to prevent a memory leak, can
you please elaborate on the scenario when a leak is observed?

>  }
>
>  int packet_classifier(odp_pktio_t pktio, odp_packet_t pkt)
> diff --git a/platform/linux-generic/pktio/loop.c
> b/platform/linux-generic/pktio/loop.c
> index 0ea6d0e..5ed4ca9 100644
> --- a/platform/linux-generic/pktio/loop.c
> +++ b/platform/linux-generic/pktio/loop.c
> @@ -70,7 +70,7 @@ static int loopback_recv(pktio_entry_t *pktio_entry,
> odp_packet_t pkts[],
> pkt_hdr = odp_packet_hdr(pkt);
> packet_parse_reset(pkt_hdr);
> packet_parse_l2(pkt_hdr);
> -   if (0 > _odp_packet_classifier(pktio_entry, pkt)) {
> +   if (_odp_packet_classifier(pktio_entry, pkt) == 1)
> {
> pkts[j++] = pkt;
> pktio_entry->s.stats.in_octets +=
> odp_packet_len(pkts[i]);
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv3] test: performance: Avoid possible out-of-bounds memory access

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

Regards,
Bala

On 6 April 2016 at 12:10, Balakrishna Garapati <
balakrishna.garap...@linaro.org> wrote:

> Resolving https://bugs.linaro.org/show_bug.cgi?id=2136 by initializing
> definite number of worker threads.
>
> Signed-off-by: Balakrishna Garapati 
> ---
>  v1: Fix for the https://bugs.linaro.org/show_bug.cgi?id=2136
>  v2: comments from v1
>  v3: Adding commit message
>
>  test/performance/odp_crypto.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/test/performance/odp_crypto.c b/test/performance/odp_crypto.c
> index fe1c7b4..0ea0b1b 100644
> --- a/test/performance/odp_crypto.c
> +++ b/test/performance/odp_crypto.c
> @@ -719,12 +719,12 @@ int main(int argc, char *argv[])
> odp_pool_t pool;
> odp_queue_param_t qparam;
> odp_pool_param_t params;
> -   odph_linux_pthread_t thr;
> odp_queue_t out_queue = ODP_QUEUE_INVALID;
> thr_arg_t thr_arg;
> -   int num_workers = 1;
> odp_cpumask_t cpumask;
> char cpumaskstr[ODP_CPUMASK_STR_SIZE];
> +   int num_workers = 1;
> +   odph_linux_pthread_t thr[num_workers];
>
> memset(&cargs, 0, sizeof(cargs));
>
> @@ -793,13 +793,15 @@ int main(int argc, char *argv[])
> printf("Run in sync mode\n");
> }
>
> +   memset(thr, 0, sizeof(thr));
> +
> if (cargs.alg_config) {
> if (cargs.schedule) {
> -   odph_linux_pthread_create(&thr, &cpumask,
> +   odph_linux_pthread_create(&thr[0], &cpumask,
>   run_thr_func,
>   &thr_arg,
>   ODP_THREAD_WORKER);
> -   odph_linux_pthread_join(&thr, num_workers);
> +   odph_linux_pthread_join(&thr[0], num_workers);
> } else {
> run_measure_one_config(&cargs, cargs.alg_config);
> }
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC] api: classification capability structure

[Bala Manoharan]

Regards,
Bala

On 12 April 2016 at 03:19, Bill Fischofer  wrote:

>
>
> On Mon, Apr 11, 2016 at 2:22 AM, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> This RFC adds classification capability structure and PMR range
>> functionality. The implementation patch will be posted once consensus
>> is reached on API definition.
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  include/odp/api/spec/classification.h | 61
>> ++-
>>  1 file changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/odp/api/spec/classification.h
>> b/include/odp/api/spec/classification.h
>> index 076b3de..1fcc520 100644
>> --- a/include/odp/api/spec/classification.h
>> +++ b/include/odp/api/spec/classification.h
>> @@ -55,6 +55,24 @@ extern "C" {
>>   */
>>
>>  /**
>> + * Classification capabilities
>> + * This capability structure defines system level classfication
>> capability
>> + */
>> +typedef struct odp_cls_capability_t {
>> +   /** PMR terms supported by the classifier,
>> +   A mask one bit for each of odp_pmr_term_t */
>> +   unsigned long long supported_pmr_terms;
>> +   /** Maximum number of PMR terms */
>> +   unsigned max_pmr_terms;
>> +   /** Number of PMR terms available for use now */
>> +   unsigned available_pmr_terms;
>> +   /** Maximum number of CoS supported */
>> +   unsigned max_cos;
>> +   /* A Boolean to denote support of PMR range */
>> +   bool pmr_range_supported;
>> +} odp_cls_capability_t;
>> +
>> +/**
>>   * class of service packet drop policies
>>   */
>>  typedef enum {
>> @@ -103,6 +121,17 @@ typedef struct odp_cls_cos_param {
>>  void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
>>
>>  /**
>> + * Query classification capabilities
>> + *
>> + * Outputs classification capabilities on success.
>> + *
>> + * @param[out] capability  Classification capability structure for
>> output
>> + * @retval 0 on success
>> + * @retval <0 on failure
>> + */
>> +int odp_cls_capability(odp_cls_capability_t *capability);
>> +
>> +/**
>>   * Create a class-of-service
>>   *
>>   * @param  nameString intended for debugging purposes.
>> @@ -272,8 +301,22 @@ typedef enum {
>>   */
>>  typedef struct odp_pmr_match_t {
>>
>
> It looks strange to call this an odp_pmr_match_t and then have a subtype
> that says whether the match is actually a match or really a range. If we're
> introducing two types of PMRs then it would seem to make is clearer to
> rename the containing struct to be odp_pmr_t.  For completeness we should
> also have an odp_pmr_init() API to do standard initialization of such for
> forward compatibility.
>

Agreed. We can name it odp_pmr_params_t since odp_pmr_t is a handle name.

>
>
>> odp_pmr_term_t  term;   /**< PMR term value to be matched */
>> -   const void  *val;   /**< Value to be matched */
>> -   const void  *mask;  /**< Masked set of bits to be matched */
>> +   bool match; /**< True if the value is match and false if
>> range */
>>
>
> Do we want match type rules to be the default or range type rules to be
> the default?  Since match is more likely to be the default it would seem to
> flip this and call the field range with range = false (i.e., match rule)
> the default.  This could also be an enum (rule_type) with the default being
> rule_type_match so that in future you could have rule types beyond just
> match or range.
>

The idea was to have match as default and yes we can flip the boolean to
make match as default. I do not foresee a scenario where the value matching
will be anything other than match and range but if it is needed we can
convert this to an enum.

Regards,
Bala

>
>
>> +   union {
>> +   struct {
>> +   /**< Value to be matched */
>> +   const void  *val;
>> +   /**< Masked set of bits to be matched */
>> +   const void  *mask;
>> +   } match;
>> +   struct {
>> +   /* Start and End values are included in the range
>> */
>> +   /**< start value of range */
>> +   const void  *val_start;
>> +   /**< End value of range */
>> +   const void  *val_end;
>> +   } range;
>> +   };
>> uint32_tval_sz;  /**< Size of the term value */
>> uint32_toffset;  /**< User-defined offset in packet
>>  Used if term == ODP_PMR_CUSTOM_FRAME
>> only,
>> @@ -323,20 +366,6 @@ odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t
>> *terms, int num_terms,
>>  int odp_cls_pmr_destroy(odp_pmr_t pmr_id);
>>
>>  /**
>> - * Inquire about matching terms supported by the classifier
>> - *
>> - * @return A mask one bit per enumerated term, one for each of
>> odp_pmr_term_t
>> - */
>> -unsigned long long odp_pmr_terms_cap(void);
>> 

[lng-odp] Requirements for Marking API

[Bala Manoharan]

Hi Barry,

Pls find below the requirements for Marking API

We need an optional ability to be able to set marking on the packet based
on the packet colour. It can be a parameter in the capability structure.

Marking on a packet can be done in the following bits of the packet.
1. VLAN drop eligibility bit (802.1Q DE)
2. DS Drop precedence RFC 2597
3. DS Explicit Congestion Notification (ECN) RFC 3168

These markings should be configurable per colour so that it would benefit
the platforms which do not support marking on GREEN colour.

Regards,
Bala
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC] api: classification capability structure

[Bala Manoharan]

On 12 April 2016 at 11:51, Maxim Uvarov  wrote:

> On 04/12/16 09:12, Bala Manoharan wrote:
>
>>
>>
>> Regards,
>> Bala
>>
>> On 12 April 2016 at 03:19, Bill Fischofer > <mailto:bill.fischo...@linaro.org>> wrote:
>>
>>
>>
>> On Mon, Apr 11, 2016 at 2:22 AM, Balasubramanian Manoharan
>> mailto:bala.manoha...@linaro.org>> wrote:
>>
>> This RFC adds classification capability structure and PMR range
>> functionality. The implementation patch will be posted once
>> consensus
>> is reached on API definition.
>>
>> Signed-off-by: Balasubramanian Manoharan
>> mailto:bala.manoha...@linaro.org>>
>> ---
>>  include/odp/api/spec/classification.h | 61
>> ++-
>>  1 file changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/odp/api/spec/classification.h
>> b/include/odp/api/spec/classification.h
>> index 076b3de..1fcc520 100644
>> --- a/include/odp/api/spec/classification.h
>> +++ b/include/odp/api/spec/classification.h
>> @@ -55,6 +55,24 @@ extern "C" {
>>   */
>>
>>  /**
>> + * Classification capabilities
>> + * This capability structure defines system level
>> classfication capability
>> + */
>> +typedef struct odp_cls_capability_t {
>> +   /** PMR terms supported by the classifier,
>> +   A mask one bit for each of odp_pmr_term_t */
>> +   unsigned long long supported_pmr_terms;
>>
>>
> in many places we use uint64_t. Here might be better to use it too for
> better match existence code style.
> (as well as unsinged - > uint32_t).
>
> Maxim.
>
>
Yes. We can change unsigned long long to uint64_t.

Regards,
Bala

> +   /** Maximum number of PMR terms */
>> +   unsigned max_pmr_terms;
>> +   /** Number of PMR terms available for use now */
>> +   unsigned available_pmr_terms;
>> +   /** Maximum number of CoS supported */
>> +   unsigned max_cos;
>> +   /* A Boolean to denote support of PMR range */
>> +   bool pmr_range_supported;
>> +} odp_cls_capability_t;
>> +
>> +/**
>>   * class of service packet drop policies
>>   */
>>  typedef enum {
>> @@ -103,6 +121,17 @@ typedef struct odp_cls_cos_param {
>>  void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
>>
>>  /**
>> + * Query classification capabilities
>> + *
>> + * Outputs classification capabilities on success.
>> + *
>> + * @param[out] capability  Classification capability
>> structure for output
>> + * @retval 0 on success
>> + * @retval <0 on failure
>> + */
>> +int odp_cls_capability(odp_cls_capability_t *capability);
>> +
>> +/**
>>   * Create a class-of-service
>>   *
>>   * @param  nameString intended for debugging purposes.
>> @@ -272,8 +301,22 @@ typedef enum {
>>   */
>>  typedef struct odp_pmr_match_t {
>>
>>
>> It looks strange to call this an odp_pmr_match_t and then have a
>> subtype that says whether the match is actually a match or really
>> a range. If we're introducing two types of PMRs then it would seem
>> to make is clearer to rename the containing struct to be
>> odp_pmr_t.  For completeness we should also have an odp_pmr_init()
>> API to do standard initialization of such for forward compatibility.
>>
>>
>> Agreed. We can name it odp_pmr_params_t since odp_pmr_t is a handle name.
>>
>> odp_pmr_term_t  term;   /**< PMR term value to be
>> matched */
>> -   const void  *val;   /**< Value to be matched */
>> -   const void  *mask;  /**< Masked set of bits to be
>> matched */
>> +   bool match; /**< True if the value is match and
>> false if range */
>>
>>
>> Do we want match type rules to be the default or range type rules
>> to be the default?  Since match is more likely to be the default
>> it would seem to flip this and call the field

Re: [lng-odp] [PATCH 1/2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

Regards,
Bala

On 12 April 2016 at 17:34, Zoltan Kiss  wrote:

>
>
> On 11/04/16 05:01, Bala Manoharan wrote:
>
>> Hi,
>>
>> Comments inline...
>>
>> Regards,
>> Bala
>>
>> On 8 April 2016 at 00:23, Zoltan Kiss > <mailto:zoltan.k...@linaro.org>> wrote:
>>
>> The callers are only interested whether there is a CoS or not. It is
>> not
>> an error if there isn't, so it has a positive return value. Any
>> other case
>> needs to release the packet, which is not handled after calling
>> queue_enq().
>>
>> Signed-off-by: Zoltan Kiss > <mailto:zoltan.k...@linaro.org>>
>> ---
>>   platform/linux-generic/odp_classification.c | 9 +++--
>>   platform/linux-generic/pktio/loop.c | 2 +-
>>   2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/platform/linux-generic/odp_classification.c
>> b/platform/linux-generic/odp_classification.c
>> index f5e4673..4f2974b 100644
>> --- a/platform/linux-generic/odp_classification.c
>> +++ b/platform/linux-generic/odp_classification.c
>> @@ -743,7 +743,7 @@ int _odp_packet_classifier(pktio_entry_t *entry,
>> odp_packet_t pkt)
>>  /* Matching PMR and selecting the CoS for the packet*/
>>  cos = pktio_select_cos(entry, pkt_addr, pkt_hdr);
>>  if (cos == NULL)
>> -   return -1;
>> +   return 1;
>>
>>
>> The scenario of NULL Cos will occur only whether there is an invalid
>> configuration done by the application. If no other CoS matches the
>> packet then default CoS will be applied, this NULL will occur only if
>> there is no defaultCoS configured and hence it is better to return the
>> error to the calling function so that a proper action could be taken.
>>
>
> Ok, then we should free the packet here as well.


IMO, we should free the packet at the loopback device function. so that
whenever the _odp_packet_classifier() function returns an error value then
the packet has to be freed by the calling function.

>
>
>
>
>>
>>  if (cos->s.pool == NULL) {
>>  odp_packet_free(pkt);
>> @@ -766,7 +766,12 @@ int _odp_packet_classifier(pktio_entry_t
>> *entry, odp_packet_t pkt)
>>
>>  /* Enqueuing the Packet based on the CoS */
>>  queue = cos->s.queue;
>> -   return queue_enq(queue,
>> odp_buf_to_hdr((odp_buffer_t)new_pkt), 0);
>> +   if (queue_enq(queue, odp_buf_to_hdr((odp_buffer_t)new_pkt),
>> 0)) {
>> +   odp_packet_free(new_pkt);
>> +   return -1;
>> +   } else {
>> +   return 0;
>> +   }
>>
>>
>> IMO packets should be freed only by the receiving module rather than by
>> the classifier in this specific error.
>>
>
> The only user, the loopback devices doesn't do so, it only adjusts the
> statistics. That is where the memory leaks btw.


Okay. Then we have to modify the loopback device function to free the
packet when there is an error in _odp_packet_classifier() function.

>
>
> The classification module drops a
>> packet only on specific cases either on error CoS or when the packet
>> pool is full.
>>
>
> Could you point me to the documentation where this behavior is described?


The scenario is described in classification users-guide documentation. Pls
let me know if we need to add additional information in the document.

>
>
> The idea of returning an error value is that the caller
>> function knows that the packet is not enqueued and it has to either free
>> the packet or check the configuration.
>>
>
> Currently we return -1, and the packet buffer is either released or not.
> The only caller doesn't care anyway, and I don't think it could do much
> more anyway, other than printing a big error message and probably abort.


Current behaviour is that when there is an error in classification, we
return -1and it means that the packet has not be enqueued into
classification queue and the buffer has not been freed.

>
>
>
>
>> You had mentioned that this patch is required to prevent a memory leak,
>> can you please elaborate on the scenario when a leak is observed?
>>
>
>
>>   }
>>
>>   int packet_classifier(odp_pktio_t pktio, odp_packet_t pkt)
>> diff --git a/platform/linux-generic/pktio/loop.c
>> b/platform/linux-generic/pk

Re: [lng-odp] [PATCH 1/2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

On 12 April 2016 at 17:41, Zoltan Kiss  wrote:

> The original behavior of loopback_recv() is incorrect then, because it
> gives back the failed packets to the caller in pkts[], some of the might
> had been already released.


The failed packets are not released by classification module. Maybe we need
to change the behaviour of the loopback_recv() function to free the packet
when there is a classification error and possibly print an error message
since the application pretty much can not do anything else in that scenario.

Regards,
Bala

>
>
> On 11/04/16 05:01, Bala Manoharan wrote:
>
>>   int packet_classifier(odp_pktio_t pktio, odp_packet_t pkt)
>> diff --git a/platform/linux-generic/pktio/loop.c
>> b/platform/linux-generic/pktio/loop.c
>> index 0ea6d0e..5ed4ca9 100644
>> --- a/platform/linux-generic/pktio/loop.c
>> +++ b/platform/linux-generic/pktio/loop.c
>> @@ -70,7 +70,7 @@ static int loopback_recv(pktio_entry_t *pktio_entry,
>> odp_packet_t pkts[],
>>  pkt_hdr = odp_packet_hdr(pkt);
>>  packet_parse_reset(pkt_hdr);
>>  packet_parse_l2(pkt_hdr);
>> -   if (0 > _odp_packet_classifier(pktio_entry, pkt))
>> {
>> +   if (_odp_packet_classifier(pktio_entry, pkt) ==
>> 1) {
>>  pkts[j++] = pkt;
>>  pktio_entry->s.stats.in_octets +=
>>  odp_packet_len(pkts[i]);
>> --
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC] api: classification capability structure

[Bala Manoharan]

Hi,

I will incorporate all these review comments in the API patch.

Regards,
Bala
On 12 April 2016 at 19:01, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>
> > -Original Message-
> > From: EXT Balasubramanian Manoharan [mailto:bala.manoha...@linaro.org]
> > Sent: Monday, April 11, 2016 10:23 AM
> > To: lng-odp@lists.linaro.org
> > Cc: Savolainen, Petri (Nokia - FI/Espoo) ;
> > Balasubramanian Manoharan 
> > Subject: [RFC] api: classification capability structure
> >
> > This RFC adds classification capability structure and PMR range
> > functionality. The implementation patch will be posted once consensus
> > is reached on API definition.
> >
> > Signed-off-by: Balasubramanian Manoharan 
> > ---
> >  include/odp/api/spec/classification.h | 61
> ++
> > -
> >  1 file changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/include/odp/api/spec/classification.h
> > b/include/odp/api/spec/classification.h
> > index 076b3de..1fcc520 100644
> > --- a/include/odp/api/spec/classification.h
> > +++ b/include/odp/api/spec/classification.h
> > @@ -55,6 +55,24 @@ extern "C" {
> >   */
> >
> >  /**
> > + * Classification capabilities
> > + * This capability structure defines system level classfication
> > capability
> > + */
> > +typedef struct odp_cls_capability_t {
> > + /** PMR terms supported by the classifier,
> > + A mask one bit for each of odp_pmr_term_t */
>
> Documentation should be wrapped into '*' prefixed lines, so that it's easy
> to find struct fields.
>
> /**
>  * bla bla
>  *
>  */
> int variable_name;
>
>
> > + unsigned long long supported_pmr_terms;
>
> Long long (coming from current API definition) should be replaced with
> better defined type. Either a bit field (see e.g. odp_pktin_hash_proto_t)
> or a uint64_t. I'd vote for bit fields since it results cleaner code for
> checking/filling flags.
>
> cap = capability();
>
> if (cap.pmr.udp_sport)
> term = ODP_PMR_UDP_SPORT;
> VS.
> if (cap.pmr & (1 << ODP_PMR_UDP_SPORT))
> term = ODP_PMR_UDP_SPORT;
>
>
>
> > + /** Maximum number of PMR terms */
> > + unsigned max_pmr_terms;
> > + /** Number of PMR terms available for use now */
> > + unsigned available_pmr_terms;
> > + /** Maximum number of CoS supported */
> > + unsigned max_cos;
> > + /* A Boolean to denote support of PMR range */
> > + bool pmr_range_supported;
>
>
> A boolean type has to be odp_bool_t.
>
>
> > +} odp_cls_capability_t;
> > +
> > +/**
> >   * class of service packet drop policies
> >   */
> >  typedef enum {
> > @@ -103,6 +121,17 @@ typedef struct odp_cls_cos_param {
> >  void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
> >
> >  /**
> > + * Query classification capabilities
> > + *
> > + * Outputs classification capabilities on success.
> > + *
> > + * @param[out]   capability  Classification capability
> structure for
> > output
> > + * @retval   0 on success
> > + * @retval   <0 on failure
> > + */
> > +int odp_cls_capability(odp_cls_capability_t *capability);
> > +
> > +/**
> >   * Create a class-of-service
> >   *
> >   * @paramnameString intended for debugging purposes.
> > @@ -272,8 +301,22 @@ typedef enum {
> >   */
> >  typedef struct odp_pmr_match_t {
> >   odp_pmr_term_t  term;   /**< PMR term value to be matched */
> > - const void  *val;   /**< Value to be matched */
> > - const void  *mask;  /**< Masked set of bits to be matched */
> > + bool match; /**< True if the value is match and false if range
> */
> > + union {
> > + struct {
> > + /**< Value to be matched */
>
> /** instead of /**<, when documentation is on top of the field.
>
> -Petri
>
>
>
> > + const void  *val;
> > + /**< Masked set of bits to be matched */
> > + const void  *mask;
> > + } match;
> > + struct {
> > + /* Start and End values are included in the range
> */
> > + /**< start value of range */
> > + const void  *val_start;
> > + /**< End value of range */
> > + const void  *val_end;
> > + } range;
> > + };
> >   uint32_tval_sz;  /**< Size of the term value */
> >   uint32_toffset;  /**< User-defined offset in packet
> >Used if term == ODP_PMR_CUSTOM_FRAME only,
> > @@ -323,20 +366,6 @@ odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t
> > *terms, int num_terms,
> >  int odp_cls_pmr_destroy(odp_pmr_t pmr_id);
> >
> >  /**
> > - * Inquire about matching terms supported by the classifier
> > - *
> > - * @return A mask one bit per enumerated term, one for each of
> > odp_pmr_term_t
> > - */
> > -unsigned long long odp_pmr_terms_cap(void);
> > -
> > -/**
> > - * Return 

Re: [lng-odp] [PATCH 1/2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

On 13 April 2016 at 19:07, Zoltan Kiss  wrote:

>
>
> On 13/04/16 13:40, Bala Manoharan wrote:
>
>>
>>
>> Regards,
>> Bala
>>
>> On 12 April 2016 at 17:34, Zoltan Kiss > <mailto:zoltan.k...@linaro.org>> wrote:
>>
>>
>>
>> On 11/04/16 05:01, Bala Manoharan wrote:
>>
>> Hi,
>>
>> Comments inline...
>>
>> Regards,
>> Bala
>>
>> On 8 April 2016 at 00:23, Zoltan Kiss > <mailto:zoltan.k...@linaro.org>
>> <mailto:zoltan.k...@linaro.org <mailto:zoltan.k...@linaro.org>>>
>> wrote:
>>
>>  The callers are only interested whether there is a CoS or
>> not. It is not
>>  an error if there isn't, so it has a positive return value.
>> Any
>>  other case
>>  needs to release the packet, which is not handled after
>> calling
>>  queue_enq().
>>
>>  Signed-off-by: Zoltan Kiss > <mailto:zoltan.k...@linaro.org>
>>  <mailto:zoltan.k...@linaro.org
>>
>> <mailto:zoltan.k...@linaro.org>>>
>>  ---
>>platform/linux-generic/odp_classification.c | 9 +++--
>>platform/linux-generic/pktio/loop.c | 2 +-
>>2 files changed, 8 insertions(+), 3 deletions(-)
>>
>>  diff --git a/platform/linux-generic/odp_classification.c
>>  b/platform/linux-generic/odp_classification.c
>>  index f5e4673..4f2974b 100644
>>  --- a/platform/linux-generic/odp_classification.c
>>  +++ b/platform/linux-generic/odp_classification.c
>>  @@ -743,7 +743,7 @@ int
>> _odp_packet_classifier(pktio_entry_t *entry,
>>  odp_packet_t pkt)
>>   /* Matching PMR and selecting the CoS for the
>> packet*/
>>   cos = pktio_select_cos(entry, pkt_addr, pkt_hdr);
>>   if (cos == NULL)
>>  -   return -1;
>>  +   return 1;
>>
>>
>> The scenario of NULL Cos will occur only whether there is an
>> invalid
>> configuration done by the application. If no other CoS matches the
>> packet then default CoS will be applied, this NULL will occur
>> only if
>> there is no defaultCoS configured and hence it is better to
>> return the
>> error to the calling function so that a proper action could be
>> taken.
>>
>>
>> Ok, then we should free the packet here as well.
>>
>>
>> IMO, we should free the packet at the loopback device function. so that
>> whenever the _odp_packet_classifier() function returns an error value
>> then the packet has to be freed by the calling function.
>>
>
> If you just look at the next few lines of this code, you'll see that this
> function releases the buffer in two error scenario.
>
>
>>
>>
>>
>>
>>
>>   if (cos->s.pool == NULL) {
>>   odp_packet_free(pkt);
>>  @@ -766,7 +766,12 @@ int _odp_packet_classifier(pktio_entry_t
>>  *entry, odp_packet_t pkt)
>>
>>   /* Enqueuing the Packet based on the CoS */
>>   queue = cos->s.queue;
>>  -   return queue_enq(queue,
>>  odp_buf_to_hdr((odp_buffer_t)new_pkt), 0);
>>  +   if (queue_enq(queue,
>> odp_buf_to_hdr((odp_buffer_t)new_pkt),
>>  0)) {
>>  +   odp_packet_free(new_pkt);
>>  +   return -1;
>>  +   } else {
>>  +   return 0;
>>  +   }
>>
>>
>> IMO packets should be freed only by the receiving module rather
>> than by
>> the classifier in this specific error.
>>
>>
>> The only user, the loopback devices doesn't do so, it only adjusts
>> the statistics. That is where the memory leaks btw.
>>
>>
>> Okay. Then we have to modify the loopback device function to free the
>> packet when there is an error in _odp_packet_classifier() function.
>>
>>
>>
>> The classification module drops a
>> packet only on specific cas

Re: [lng-odp] [PATCH 1/2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

On 13 April 2016 at 19:51, Zoltan Kiss  wrote:

> Hi,
>
> I've sent a new patch, I just wanted to mention that I couldn't find this
> behavior described in user-guide-cls.adoc
>

I will add these information to user-guide document.

Regards,
Bala

>
> Zoli
>
> On 13/04/16 13:40, Bala Manoharan wrote:
>
>>
>>
>> The classification module drops a
>> packet only on specific cases either on error CoS or when the
>> packet
>> pool is full.
>>
>>
>> Could you point me to the documentation where this behavior is
>> described?
>>
>>
>> The scenario is described in classification users-guide documentation.
>> Pls let me know if we need to add additional information in the document.
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH v2] linux-generic: classification: fix error checking _odp_packet_classifier()

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

On 13 April 2016 at 19:50, Zoltan Kiss  wrote:

> In case of error the 'pkt' should be released by the calling function.
> Currently loopback gives it back to the receiver and report it as success
> in the stats.
>
> Signed-off-by: Zoltan Kiss 
> ---
>
> v2: handle release in caller instead, and adjust stats.
>
>  platform/linux-generic/odp_classification.c | 10 +++---
>  platform/linux-generic/pktio/loop.c |  9 ++---
>  2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/platform/linux-generic/odp_classification.c
> b/platform/linux-generic/odp_classification.c
> index 8522023..3a18a78 100644
> --- a/platform/linux-generic/odp_classification.c
> +++ b/platform/linux-generic/odp_classification.c
> @@ -745,21 +745,17 @@ int _odp_packet_classifier(pktio_entry_t *entry,
> odp_packet_t pkt)
> if (cos == NULL)
> return -1;
>
> -   if (cos->s.pool == NULL) {
> -   odp_packet_free(pkt);
> +   if (cos->s.pool == NULL)
> return -1;
> -   }
>
> -   if (cos->s.queue == NULL) {
> -   odp_packet_free(pkt);
> +   if (cos->s.queue == NULL)
> return -1;
> -   }
>
> if (odp_packet_pool(pkt) != cos->s.pool->s.pool_hdl) {
> new_pkt = odp_packet_copy(pkt, cos->s.pool->s.pool_hdl);
> -   odp_packet_free(pkt);
> if (new_pkt == ODP_PACKET_INVALID)
> return -1;
> +   odp_packet_free(pkt);
> } else {
> new_pkt = pkt;
> }
> diff --git a/platform/linux-generic/pktio/loop.c
> b/platform/linux-generic/pktio/loop.c
> index 0ea6d0e..f6a8c1d 100644
> --- a/platform/linux-generic/pktio/loop.c
> +++ b/platform/linux-generic/pktio/loop.c
> @@ -70,10 +70,13 @@ static int loopback_recv(pktio_entry_t *pktio_entry,
> odp_packet_t pkts[],
> pkt_hdr = odp_packet_hdr(pkt);
> packet_parse_reset(pkt_hdr);
> packet_parse_l2(pkt_hdr);
> -   if (0 > _odp_packet_classifier(pktio_entry, pkt)) {
> -   pkts[j++] = pkt;
> +   if (!_odp_packet_classifier(pktio_entry, pkt)) {
> pktio_entry->s.stats.in_octets +=
> -   odp_packet_len(pkts[i]);
> +   odp_packet_len(pkt);
> +   } else {
> +   pktio_entry->s.stats.in_errors +=
> +   odp_packet_len(pkt);
> +   odp_packet_free(pkt);
> }
> }
> nbr = j;
> --
> 1.9.1
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv1] fix: incorrect pmr_term_value update in odp_pmr_create_xxx() function

[bala . manoharan]

From: Balasubramanian Manoharan 

Fix for incorrect pmr_term_value update in odp_pmr_create_match() and 
odp_pmr_create_range() functions.
Fixes https://bugs.linaro.org/show_bug.cgi?id=1381

Signed-off-by: Balasubramanian Manoharan 
---
 platform/linux-generic/odp_classification.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index 9fb034f..b7a4fe6 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -438,6 +438,7 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term,
pmr->s.pmr_term_value[0].mask.mask =  0;
memcpy(&pmr->s.pmr_term_value[0].mask.val, val, val_sz);
memcpy(&pmr->s.pmr_term_value[0].mask.mask, mask, val_sz);
+   pmr->s.pmr_term_value[0].mask.val &= pmr->s.pmr_term_value[0].mask.mask;
UNLOCK(&pmr->s.lock);
return id;
 }
@@ -460,7 +461,7 @@ odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term,
return ODP_PMR_INVAL;
 
pmr->s.num_pmr = 1;
-   pmr->s.pmr_term_value[0].match_type = ODP_PMR_MASK;
+   pmr->s.pmr_term_value[0].match_type = ODP_PMR_RANGE;
pmr->s.pmr_term_value[0].term = term;
pmr->s.pmr_term_value[0].range.val1 =  0;
pmr->s.pmr_term_value[0].range.val2 =  0;
@@ -601,6 +602,7 @@ int odp_pmr_match_set_create(int num_terms, odp_pmr_match_t 
*terms,
   terms[i].mask.val, val_sz);
memcpy(&pmr->s.pmr_term_value[i].mask.mask,
   terms[i].mask.mask, val_sz);
+   pmr->s.pmr_term_value[i].mask.val &= 
pmr->s.pmr_term_value[i].mask.mask;
} else {
val_sz = terms[i].range.val_sz;
if (val_sz > ODP_PMR_TERM_BYTES_MAX)
-- 
2.0.1.472.g6f92e5f


___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv1] example: ODP Classifier example

[bala . manoharan]

From: Balasubramanian Manoharan 

ODP Classifier example

This programs gets pmr rules as command-line parameter and configures the 
classification engine
in the system.

This initial version supports the following
* ODP_PMR_SIP_ADDR pmr term
* PMR term MATCH and RANGE type
* Multiple PMR rule can be set on a single pktio interface with different 
queues associated to each PMR rule
* Automatically configures a default queue and provides statistics for the same
* Prints statistics interms of the number of packets dispatched to each queue

Signed-off-by: Balasubramanian Manoharan 
---
 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/classifier/Makefile.am  |  10 +
 example/classifier/odp_classifier.c | 759 
 4 files changed, 771 insertions(+), 1 deletion(-)
 create mode 100644 example/classifier/Makefile.am
 create mode 100644 example/classifier/odp_classifier.c

diff --git a/configure.ac b/configure.ac
index 57054c5..51e4834 100644
--- a/configure.ac
+++ b/configure.ac
@@ -255,6 +255,7 @@ AC_CONFIG_FILES([Makefile
 example/l2fwd/Makefile
 example/packet/Makefile
 example/timer/Makefile
+example/classifier/Makefile
 pkgconfig/libodp.pc
 platform/Makefile
 platform/linux-generic/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 3021571..aa09a8e 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec l2fwd packet timer
+SUBDIRS = generator ipsec l2fwd packet timer classifier
diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
new file mode 100644
index 000..938f094
--- /dev/null
+++ b/example/classifier/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_classifier
+odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
+odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_classifier_SOURCES = odp_classifier.c
diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
new file mode 100644
index 000..8b34e7d
--- /dev/null
+++ b/example/classifier/odp_classifier.c
@@ -0,0 +1,759 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** @def MAX_WORKERS
+ * @brief Maximum number of worker threads
+ */
+#define MAX_WORKERS32
+
+/** @def SHM_PKT_POOL_SIZE
+ * @brief Size of the shared memory block
+ */
+#define SHM_PKT_POOL_SIZE  (512*2048)
+
+/** @def SHM_PKT_POOL_BUF_SIZE
+ * @brief Buffer size of the packet pool buffer
+ */
+#define SHM_PKT_POOL_BUF_SIZE  1856
+
+/** @def MAX_PMR_COUNT
+ * @brief Maximum number of Classification Policy
+ */
+#define MAX_PMR_COUNT  8
+
+/** @def DISPLAY_STRING_LEN
+ * @brief Length of string used to display term value
+ */
+#define DISPLAY_STRING_LEN 32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   odp_queue_t queue;  /**< Associated queue handle */
+   odp_cos_t cos;  /**< Associated cos handle */
+   odp_pmr_t pmr;  /**< Associated pmr handle */
+   odp_atomic_u64_t packet_count;  /**< count of received packets */
+   odp_pmr_term_e term;/**< odp pmr term value */
+   char queuename[ODP_QUEUE_NAME_LEN]; /**< queue name */
+   odp_pmr_match_type_e match_type;/**< pmr match type */
+   int val_sz; /**< size of the pmr term */
+   union {
+   struct {
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } match;
+   struct  {
+   uint32_t val1;  /**< pmr term start range */
+   uint32_t val2;  /**< pmr term end range */
+   } range;
+   };
+   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
+   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
+} global_statistics;
+
+static global_statistics stats[MAX_PMR_COUNT];
+static int policy_count;
+static int queue_count;
+static int appl_mode;
+static odp_atomic_u64_t total_packets;
+
+enum packet_mode {
+   APPL_MODE_DROP, /**< Packet is dropped */
+   APPL_MODE_REPLY /**< Packet is sent back */
+};
+
+/**
+ * Parsed command line application arguments
+ */
+typedef struct {
+   int cpu_count;  /**< Number of CPUs to use */
+   char *if_name;  /**< pointer to interface name

Re: [lng-odp] [PATCHv1] example: ODP Classifier example

[Bala Manoharan]

This example has dependency with the following bug fix:
https://patches.linaro.org/46130/

Regards,
Bala

On 20 March 2015 at 12:37,   wrote:
> From: Balasubramanian Manoharan 
>
> ODP Classifier example
>
> This programs gets pmr rules as command-line parameter and configures the 
> classification engine
> in the system.
>
> This initial version supports the following
> * ODP_PMR_SIP_ADDR pmr term
> * PMR term MATCH and RANGE type
> * Multiple PMR rule can be set on a single pktio interface with different 
> queues associated to each PMR rule
> * Automatically configures a default queue and provides statistics for the 
> same
> * Prints statistics interms of the number of packets dispatched to each queue
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  configure.ac|   1 +
>  example/Makefile.am |   2 +-
>  example/classifier/Makefile.am  |  10 +
>  example/classifier/odp_classifier.c | 759 
> 
>  4 files changed, 771 insertions(+), 1 deletion(-)
>  create mode 100644 example/classifier/Makefile.am
>  create mode 100644 example/classifier/odp_classifier.c
>
> diff --git a/configure.ac b/configure.ac
> index 57054c5..51e4834 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -255,6 +255,7 @@ AC_CONFIG_FILES([Makefile
>  example/l2fwd/Makefile
>  example/packet/Makefile
>  example/timer/Makefile
> +example/classifier/Makefile
>  pkgconfig/libodp.pc
>  platform/Makefile
>  platform/linux-generic/Makefile
> diff --git a/example/Makefile.am b/example/Makefile.am
> index 3021571..aa09a8e 100644
> --- a/example/Makefile.am
> +++ b/example/Makefile.am
> @@ -1 +1 @@
> -SUBDIRS = generator ipsec l2fwd packet timer
> +SUBDIRS = generator ipsec l2fwd packet timer classifier
> diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
> new file mode 100644
> index 000..938f094
> --- /dev/null
> +++ b/example/classifier/Makefile.am
> @@ -0,0 +1,10 @@
> +include $(top_srcdir)/example/Makefile.inc
> +
> +bin_PROGRAMS = odp_classifier
> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
> +
> +noinst_HEADERS = \
> + $(top_srcdir)/example/example_debug.h
> +
> +dist_odp_classifier_SOURCES = odp_classifier.c
> diff --git a/example/classifier/odp_classifier.c 
> b/example/classifier/odp_classifier.c
> new file mode 100644
> index 000..8b34e7d
> --- /dev/null
> +++ b/example/classifier/odp_classifier.c
> @@ -0,0 +1,759 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/** @def MAX_WORKERS
> + * @brief Maximum number of worker threads
> + */
> +#define MAX_WORKERS32
> +
> +/** @def SHM_PKT_POOL_SIZE
> + * @brief Size of the shared memory block
> + */
> +#define SHM_PKT_POOL_SIZE  (512*2048)
> +
> +/** @def SHM_PKT_POOL_BUF_SIZE
> + * @brief Buffer size of the packet pool buffer
> + */
> +#define SHM_PKT_POOL_BUF_SIZE  1856
> +
> +/** @def MAX_PMR_COUNT
> + * @brief Maximum number of Classification Policy
> + */
> +#define MAX_PMR_COUNT  8
> +
> +/** @def DISPLAY_STRING_LEN
> + * @brief Length of string used to display term value
> + */
> +#define DISPLAY_STRING_LEN 32
> +
> +/** Get rid of path in filename - only for unix-type paths using '/' */
> +#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
> +   strrchr((file_name), '/') + 1 : (file_name))
> +
> +typedef struct {
> +   odp_queue_t queue;  /**< Associated queue handle */
> +   odp_cos_t cos;  /**< Associated cos handle */
> +   odp_pmr_t pmr;  /**< Associated pmr handle */
> +   odp_atomic_u64_t packet_count;  /**< count of received packets */
> +   odp_pmr_term_e term;/**< odp pmr term value */
> +   char queuename[ODP_QUEUE_NAME_LEN]; /**< queue name */
> +   odp_pmr_match_type_e match_type;/**< pmr match type */
> +   int val_sz; /**< size of the pmr term */
> +   union {
> +   struct {
> +   uint32_t val;   /**< pmr term value */
> +   uint32_t mask;  /**< pmr term mask */
> +   } match;
> +   struct  {
> +   uint32_t val1;  /**< pmr term start range */
> +   uint32_t val2;  /**< pmr term end range */
> +   } range;
> +   };
> +   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
> +   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
> +} global_statistics;
> +
> +static global_statistics stats[MAX_PMR_COUNT];
> +static int policy_count;
> +stat

Re: [lng-odp] [RFC v3 0/4] Move the definition of odp syncronizers abstract types to platform

[Bala Manoharan]

For this series.
Reviewed-by: Bala Manoharan

On 20 March 2015 at 17:44, Jerin Jacob  wrote:
> On Wed, Mar 18, 2015 at 11:29:03AM -0500, Bill Fischofer wrote:
>
> Ping
>
>> This version looks good.  For this series:
>>
>> Reviewed-and-tested-by: Bill Fischofer 
>>
>> On Wed, Mar 18, 2015 at 9:11 AM, Jerin Jacob > > wrote:
>>
>> > Move the definition of odp syncronizers abstract types to platform
>> > from public headerfile.
>> > This will allow the platform to define odp syncronizers abstract type.
>> > Useful when native SDK has definition of the odp syncronizers and
>> > ODP implementation decides to reuses them.
>> >
>> > v1..v2 Corrected the Doxygen documentation issues identified by Petri
>> > v2..v3 Fixed compilation issues in 'make distcheck' identified by Bill
>> >
>> >
>> > Jerin Jacob (4):
>> >   spinlock: allow platform to override odp_spinlock_t
>> >   rwlock: allow platform to override odp_rwlock_t
>> >   ticketlock: allow platform to override odp_ticketlock_t
>> >   barrier: allow platform to override odp_barrier_t
>> >
>> >  include/odp/api/barrier.h  |  7 +---
>> >  include/odp/api/rwlock.h   | 11 +
>> >  include/odp/api/spinlock.h | 10 +
>> >  include/odp/api/ticketlock.h   | 12 +-
>> >  platform/linux-generic/Makefile.am |  4 ++
>> >  platform/linux-generic/include/odp/barrier.h   |  1 +
>> >  .../linux-generic/include/odp/plat/barrier_types.h | 47
>> > +
>> >  .../linux-generic/include/odp/plat/rwlock_types.h  | 48
>> > ++
>> >  .../include/odp/plat/spinlock_types.h  | 46
>> > +
>> >  .../include/odp/plat/ticketlock_types.h| 46
>> > +
>> >  platform/linux-generic/include/odp/rwlock.h|  2 +
>> >  platform/linux-generic/include/odp/spinlock.h  |  2 +
>> >  platform/linux-generic/include/odp/ticketlock.h|  2 +
>> >  13 files changed, 205 insertions(+), 33 deletions(-)
>> >  create mode 100644 platform/linux-generic/include/odp/plat/barrier_types.h
>> >  create mode 100644 platform/linux-generic/include/odp/plat/rwlock_types.h
>> >  create mode 100644
>> > platform/linux-generic/include/odp/plat/spinlock_types.h
>> >  create mode 100644
>> > platform/linux-generic/include/odp/plat/ticketlock_types.h
>> >
>> > --
>> > 2.1.0
>> >
>> >
>> > ___
>> > lng-odp mailing list
>> > lng-odp@lists.linaro.org
>> > http://lists.linaro.org/mailman/listinfo/lng-odp
>> >
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv2] fix: incorrect pmr_term_value update in odp_pmr_create_xxx() function

[bala . manoharan]

From: Balasubramanian Manoharan 

Fix for incorrect pmr_term_value update in odp_pmr_create_match() and 
odp_pmr_create_range() functions.
Fixes https://bugs.linaro.org/show_bug.cgi?id=1381

Signed-off-by: Balasubramanian Manoharan 
---
v2: Fixes checkpatch issue pointed by Bill

 platform/linux-generic/odp_classification.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index 9fb034f..609faa9 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -438,6 +438,7 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term,
pmr->s.pmr_term_value[0].mask.mask =  0;
memcpy(&pmr->s.pmr_term_value[0].mask.val, val, val_sz);
memcpy(&pmr->s.pmr_term_value[0].mask.mask, mask, val_sz);
+   pmr->s.pmr_term_value[0].mask.val &= pmr->s.pmr_term_value[0].mask.mask;
UNLOCK(&pmr->s.lock);
return id;
 }
@@ -460,7 +461,7 @@ odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term,
return ODP_PMR_INVAL;
 
pmr->s.num_pmr = 1;
-   pmr->s.pmr_term_value[0].match_type = ODP_PMR_MASK;
+   pmr->s.pmr_term_value[0].match_type = ODP_PMR_RANGE;
pmr->s.pmr_term_value[0].term = term;
pmr->s.pmr_term_value[0].range.val1 =  0;
pmr->s.pmr_term_value[0].range.val2 =  0;
@@ -601,6 +602,8 @@ int odp_pmr_match_set_create(int num_terms, odp_pmr_match_t 
*terms,
   terms[i].mask.val, val_sz);
memcpy(&pmr->s.pmr_term_value[i].mask.mask,
   terms[i].mask.mask, val_sz);
+   pmr->s.pmr_term_value[i].mask.val &= pmr->s
+   .pmr_term_value[i].mask.mask;
} else {
val_sz = terms[i].range.val_sz;
if (val_sz > ODP_PMR_TERM_BYTES_MAX)
-- 
2.0.1.472.g6f92e5f


___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC 5/8] api: packet_io: added packet input queue API definitions

[Bala Manoharan]

Hi,

Since we have the concept of a default CoS in classification, why cant
we associate the above APIs to default CoS, in that way we can avoid
linking this hash function directly to pktio.

coz there comes a discrepancy now as to what happens when both this
API and classification are configured at the same time.

Regards,
Bala

On 31 March 2015 at 18:57, Alexandru Badicioiu
 wrote:
>
>
> On 31 March 2015 at 16:09, Ola Liljedahl  wrote:
>>
>> On 31 March 2015 at 14:49, Alexandru Badicioiu
>>  wrote:
>>>
>>> There are some issues queue groups in the classification API :
>>
>> Then I think we should clean up those issues in that API. Not invent
>> similar (queue distribution) support in a different API.
>>
>>
>>>
>>> Distribution is too restrictive (based on ranges) and it may not be
>>> widely supported.
>>
>> Exactly to what level the classification API is supported is
>> implementation specific. But perhaps some things are too specific and will
>> not be widely supported. We need feedback from the SoC vendors.
>>
>> I can imagine that when a packet has been successfully matched, the CoS
>> could specify a contiguous set of bits (i.e. a bit field) in the packet
>> which is used for distributing matching packets to a range of queues. I know
>> we discussed this but currently it is only possible to assign *one* queue to
>> a CoS. Lots of things didn't make it to the 1.0 API.
>>
>>> "This means that when the classifier matches an inbound packet to the
>>> specified CoS, the packet will be distributed among the queues of the
>>> specified queue group based on the index value of the PMR range.  If the
>>> range value runs [startval..endval] for a field then a packet assigned to
>>> this CoS that has a field value of val in this range will be enqueued to
>>> queue val-startval of the queue group."
>>
>> Where is this text from? I can't find it in the header files. Is it from
>> the original classification design document?
>
> Queue & scheduler API -
> https://docs.google.com/a/linaro.org/document/d/1h0g7OEQst_PlOauNIHKmIyqK9Bofiv9L-bn9slRaBZ8/edit#
>>
>>
>>>
>>>
>>> Packet field value matching has to be performed before doing the
>>> distribution. Using only packet field type in the distribution spec does not
>>> involve any matching (only information the provided by parser - field
>>> present/not present).
>>>
>>> Alex
>>>
>>>
>>>
>>> On 31 March 2015 at 14:48, Ola Liljedahl 
>>> wrote:

 On 31 March 2015 at 13:39, Alexandru Badicioiu
  wrote:
>
> In my understanding of the terms, distribution computes the queue id
> from the various packet fields/bytes (and maybe other data like port id)
> usually with a hashing function. Classification uses table lookup to find
> the queue id associated with a given key.Classification tables can be
> cascaded while distributions cannot. Distribution is used typically for
> spreading the load to a group of cores while classification deals with
> separating logical flows with different processing requirements (e.g.
> different IPsec SA, VLANs, etc).

 It is not a question which terms to use or what they mean.
 I claim that this distribution functionality is already supported in the
 classification API (where you can specify a range of queues as the
 destination, not only one queue). So do we need to add a similar feature to
 the pktio API?

 I think the abstraction level is too low if we think we need to add such
 a feature to different API's. How different ODP implementations implement
 this feature is a different thing. Maybe some ODP implementation only
 supports five-tuple hashing in the NIC (which corresponds to the pktio) but
 this should still be possible to control using the classification API. The
 idea is that ODP abstracts the underlying HW, not exposes it.

 Perhaps we should rename it to classification and distribution API if
 this eases the confusion?
>
>
> Alex
>
> On 31 March 2015 at 14:15, Ola Liljedahl 
> wrote:
>>
>> On 31 March 2015 at 10:56, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>>>
>>> Hi Alex,
>>>
>>>
>>>
>>> Could you explain a bit more what you mean with extracts here.
>>> Detailed classification (packet field + mask/range => queue / set of 
>>> queues)
>>> would be still handled with classification API. This API would offer an 
>>> easy
>>> way to spread typical flows (e.g. 5-tuple) into multiple queues (same 
>>> queue
>>> type, priority, sync, group).
>>
>> Yes I was thinking that hash-based distribution is already supported
>> (or at least the rudiments are in place to support it) by the 
>> classification
>> API.
>> Isn't this pktio support redundant? Why have it in both places?
>>
>> -- Ola
>>
>>
>>>
>>>
>>>
>>> -Petri
>>>
>>>
>>>
>>>
>>>
>>> From: ext Alexandru

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

[Bala Manoharan]

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?
>>
>> @Taras:
>> Assume: set several pools per pktio interface.
>> What will happen if two data plane applications share one physical
>> Ethernet port to receive packets?
>> Since the pool is per pktio interface, will these two applications share
>> the same buffer pool?
>> If there is memory leak in one application, the other application will be
>> disturbed.
>> Correct me if my understanding were wrong.
>
>
> That's a nice question. I'm afraid this use-case was not considered before.
> Do you want to split traffic between two applications via classifier?
>
>>
>> Maybe to let each CoS have more than one pool and limit the max number of
>> Pool to for example 4 (Let the application designer decide how many pools
>> are needed for each CoS) could be one option.

Hi,

If we are attaching multiple pools per CoS what will be the
distribution algorithm for packets to each of the associated pools?
will it be a simple round-robin in that case wouldn't it be better to
attach a single pool of bigger size to the specific CoS?

Since we are attaching pools per CoS object the application can
configure the PMR rule in such a way that packets which come from the
same interface and belong to different service can be configured to be
allocated from multiple pools by attaching to multiple CoS objects.
Pls let me know if my understanding is wrong.

Regards,
Bala
>
>
> That is a possible solution.
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

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

[Bala Manoharan]

On 6 April 2015 at 16:34, Bill Fischofer  wrote:
> Isn't that just another term in the PMR?  If I have a flow with four
> different sized packets that I want to put in different pools then I simply
> have a PMR to identify the flow as input to other PMRs that then segregate
> by pkt_len into four final CoSes which map the flow to the same queue but
> different pools.

I have the same opinion as Bill and I believe this approach gives
freedom to application to configure which packet_len should go into
which pool.

Regards,
Bala
>
> On Mon, Apr 6, 2015 at 5:28 AM, Taras Kondratiuk
>  wrote:
>>
>> On 04/03/2015 07:53 PM, Bala Manoharan wrote:
>>>
>>> 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?
>>>>>
>>>>> @Taras:
>>>>> Assume: set several pools per pktio interface.
>>>>> What will happen if two data plane applications share one physical
>>>>> Ethernet port to receive packets?
>>>>> Since the pool is per pktio interface, will these two applications
>>>>> share
>>>>> the same buffer pool?
>>>>> If there is memory leak in one application, the other application will
>>>>> be
>>>>> disturbed.
>>>>> Correct me if my understanding were wrong.
>>>>
>>>>
>>>>
>>>> That's a nice question. I'm afraid this use-case was not considered
>>>> before.
>>>> Do you want to split traffic between two applications via classifier?
>>>>
>>>>>
>>>>> Maybe to let each CoS have more than one pool and limit the max number
>>>>> of
>>>>> Pool to for example 4 (Let the application designer decide how many
>>>>> pools
>>>>> are needed for each CoS) could be one option.
>>>
>>>
>>> Hi,
>>>
>>> If we are attaching multiple pools per CoS what will be the
>>> distribution algorithm for packets to each of the associated pools?
>>> will it be a simple round-robin in that case wouldn't it be better to
>>> attach a single pool of bigger size to the specific CoS?
>>
>>
>> Packets will be distributed deterministically according to size.
>>
>> In fact distributing packets to different pools by their sizes is
>> orthogonal to the rest of classification which is done by analyzing
>> packet (header) content. IMO it was a mistake to combine them. They
>> normally have different purposes. Classification by size is used to get
>> efficient memory usage and decrease packet segmentation. While content
>> classification is used to separate different 'types' of traffic.
>>
>> In KS2 platform these are two separate steps:
>> 1. Packet is classified by a header content and directed to a Flow
>>(ODP CoS analog).
>> 2. Flow has a destination queue and up to 4 pools assigned. Exact pool
>>is chosen based on a packet size.
>>
>> Actually, the initial use-case in this thread clearly demonstrates
>> orthogonality of packet content and size classification: number of CoS'es
>> explodes as *.
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

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

[Bala Manoharan]

I would like to get application use-case for different scenarios where
this would be useful before finalizing "pool groups" and their API
signature.
Also in the above proposal it is not possible to combine multiple
pools to form a pool group, I like this idea as it gives freedom for
implementation to allocate and optimize the individual pools.

Regards,
Bala

On 6 April 2015 at 22:11, Bill Fischofer  wrote:
> I would call these "pool groups" for symmetry with "queue groups" and so the
> API would be odp_pool_create_group(), odp_pool_destroy_group(), etc.
>
> On Mon, Apr 6, 2015 at 11:35 AM, Taras Kondratiuk
>  wrote:
>>
>> On 04/06/2015 03:31 PM, Bill Fischofer wrote:
>> > The /expression/ may be linear, but that doesn't imply that is how any
>> > given implementation needs to realize the expression.  Since PMRs are
>> > reasonably static, I'd expect them to be "compiled" into whatever native
>> > classification capabilities are present in the platform.  Real
>> > classification is typically done in parallel by the HW as the packet is
>> > coming "off the wire".  This is necessary because one of the outputs of
>> > classification is pool selection, so all of this happens while the
>> > packet is in the HW's receive FIFO before the DMA engines are told where
>> > to store it.
>>
>> Following our discussion on a call.
>>
>> Choosing a pool on ingress solves two separate issues:
>> 1. Isolation - packets that belong to different CoS'es may need to use
>>separate packet pools. Pool choice is strictly deterministic.
>>This case is covered by current API.
>> 2. Segmentation optimization - application may want to sort packets of
>>different size into pools with different segment size. In this case
>>pool choice is not very strict. For example a small packet can be
>>allocated from a pool with big segments if small-segment pool is
>>empty. This case can't be expressed with a current API.
>>
>> Assigning several pools to CoS and allowing implementation to pick an
>> optimal pool would be one option to solve #2.
>> During a meeting Maxim proposed to use a 'composite' pool instead, and
>> I like this idea more. I imagine something like this:
>>
>> /**
>>  * Create a composite pool
>>  *
>>  * This routine is used to create a pool which logically consists of
>>  * a set of sub-pools. Each sub-pool has its own configuration
>>  * parameters. Only pool of ODP_POOL_PACKET type can be created.
>>  * On allocation an implementation will choose an optimal sub-pool to
>>  * allocate a packet from.
>>  * A composite pool can be used to optimize memory usage and minimize
>>  * packet segmentation.
>>  *
>>  * @param name  Name of the pool, max ODP_POOL_NAME_LEN-1 chars.
>>  *  May be specified as NULL for anonymous pools.
>>  *
>>  * @param shm   The shared memory object in which to create the pool.
>>  *  Use ODP_SHM_NULL to reserve default memory type
>>  *  for the pool type.
>>  *
>>  * @param num_pools Number of sub-pools in a composite pool
>>  *
>>  * @param paramsArray of sub-pools' parameters.
>>  *
>>  * @return Handle of the created pool
>>  * @retval ODP_POOL_INVALID  Pool could not be created
>>  */
>>
>> odp_pool_t odp_pool_create_composite(const char *name,
>>odp_shm_t shm,
>>uint32_t num_pools,
>>odp_pool_param_t *params[]);
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv2] example: ODP classifier example

[bala . manoharan]

From: Balasubramanian Manoharan 

ODP Classifier example

This programs gets pmr rules as command-line parameter and configures the 
classification engine
in the system.

This initial version supports the following
* ODP_PMR_SIP_ADDR pmr term
* PMR term MATCH and RANGE type
* Multiple PMR rule can be set on a single pktio interface with different 
queues associated to each PMR rule
* Automatically configures a default queue and provides statistics for the same
* Prints statistics interms of the number of packets dispatched to each queue


Signed-off-by: Balasubramanian Manoharan 
---
v2: Incorporates review comments from Maxim
Resending V2 as there were some issue in linaro mail server

 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/classifier/Makefile.am  |  10 +
 example/classifier/odp_classifier.c | 789 
 4 files changed, 801 insertions(+), 1 deletion(-)
 create mode 100644 example/classifier/Makefile.am
 create mode 100644 example/classifier/odp_classifier.c

diff --git a/configure.ac b/configure.ac
index 57054c5..d8d8ca5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -250,6 +250,7 @@ AM_CXXFLAGS="-std=c++11"
 AC_CONFIG_FILES([Makefile
 doc/Makefile
 example/Makefile
+example/classifier/Makefile
 example/generator/Makefile
 example/ipsec/Makefile
 example/l2fwd/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 3021571..33b60c1 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec l2fwd packet timer
+SUBDIRS = classifier generator ipsec l2fwd packet timer
diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
new file mode 100644
index 000..938f094
--- /dev/null
+++ b/example/classifier/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_classifier
+odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
+odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_classifier_SOURCES = odp_classifier.c
diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
new file mode 100644
index 000..f3dcbbb
--- /dev/null
+++ b/example/classifier/odp_classifier.c
@@ -0,0 +1,789 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** @def MAX_WORKERS
+ * @brief Maximum number of worker threads
+ */
+#define MAX_WORKERS32
+
+/** @def SHM_PKT_POOL_SIZE
+ * @brief Size of the shared memory block
+ */
+#define SHM_PKT_POOL_SIZE  (512*2048)
+
+/** @def SHM_PKT_POOL_BUF_SIZE
+ * @brief Buffer size of the packet pool buffer
+ */
+#define SHM_PKT_POOL_BUF_SIZE  1856
+
+/** @def MAX_PMR_COUNT
+ * @brief Maximum number of Classification Policy
+ */
+#define MAX_PMR_COUNT  8
+
+/** @def DISPLAY_STRING_LEN
+ * @brief Length of string used to display term value
+ */
+#define DISPLAY_STRING_LEN 32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   odp_queue_t queue;  /**< Associated queue handle */
+   odp_cos_t cos;  /**< Associated cos handle */
+   odp_pmr_t pmr;  /**< Associated pmr handle */
+   odp_atomic_u64_t packet_count;  /**< count of received packets */
+   odp_pmr_term_e term;/**< odp pmr term value */
+   char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
+   odp_pmr_match_type_e match_type;/**< pmr match type */
+   int val_sz; /**< size of the pmr term */
+   union {
+   struct {
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } match;
+   struct  {
+   uint32_t val1;  /**< pmr term start range */
+   uint32_t val2;  /**< pmr term end range */
+   } range;
+   };
+   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
+   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
+} global_statistics;
+
+typedef struct {
+   global_statistics stats[MAX_PMR_COUNT];
+   int policy_count;   /**< global policy count */
+   int appl_mode;  /**< application mode */
+   odp_atomic_u64_t total_packets; /**< total received packets */
+   int cpu_count;  /**< Number of CPUs to use */
+   char *if_name;  /**< pointer to interface names */
+} appl_args_t;
+
+enum packet_mode {
+  

Re: [lng-odp] [RFC] api: classification: Create PMR handle on its application

[Bala Manoharan]

On 9 April 2015 at 14:38, Taras Kondratiuk  wrote:
> + mailing list that I've missed initially in the RFC.
>
> On 04/08/2015 10:25 PM, Rosenboim, Leonid wrote:
>>
>> Taras,
>>
>> I actually agree with you that a change in the API is justified
>> that combines the in and out CoS values are provided at the time
>> of PMR creation, instead of using a separate function.
>> The main reason is that the input CoS is one of the rules that
>> the ternary CAM must match, and the output CoS is the action
>> that it must be assigned.
>>
>> Here the key changes I propose, granted that there will
>> need to be additional changes made in other APIs in a similar manner.
>
>
> Yes this is an alternative approach.
>
> odp_pktio_pmr_cos() should be renamed to something like
> odp_pktio_cos_set()
> Is there still an implicit 'default' CoS assigned to Pktio on
> odp_pktio_open()? Or this function should be used to set a default one?

IMO, it might be better to have assigning of default CoS as a separate
function rather than on odp_pktio_open() since it gives freedom for
platforms which do not support classifier and also it treats
classifier as a separate module

Regards,
Bala
>
> This approach highlights one more implementation issue on my platform:
> CoS (pool and queue) assignment is the last step of classification, so
> CoS'es cannot be cascaded directly. Instead PMRs (LUT entries) are
> cascaded. CoS cascading can be mapped to PMRs cascading in simple
> use-cases, but if a first CoS has a several PMRs pointing to it, then
> next cascaded CoS will lead to creation of multiple LUT entries.
> I'll think how it can mapped in a better way.
>
>
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index 7db3645..b511cb4 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -232,6 +232,9 @@ typedef enum odp_pmr_term {
>>* @param[in] val_sz  Size of the val and mask arguments,
>>*that must match the value size requirement of the
>>*specific term.
>> + * @param[in]  src_cos CoS to be filtered
>> + * @param[in]  dst_cos CoS to be assigned to packets filtered
>> + * from src_cos that match pmr_id.
>>*
>>* @returnHandle of the matching rule
>>* @retvalODP_PMR_INVAL on failure
>> @@ -239,7 +242,9 @@ typedef enum odp_pmr_term {
>>   odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term,
>>const void *val,
>>const void *mask,
>> -  uint32_t val_sz);
>> +  uint32_t val_sz,
>> +  odp_cos_t src_cos,
>> +  odp_cos_t dst_cos);
>>
>>   /**
>>* Create a packet match rule with value range
>> @@ -250,6 +255,9 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term,
>>* @param[in] val_sz  Size of the val1 and val2 arguments,
>>*that must match the value size requirement of the
>>*specific term.
>> + * @param[in]  src_cos CoS to be filtered
>> + * @param[in]  dst_cos CoS to be assigned to packets filtered
>> + * from src_cos that match pmr_id.
>>*
>>* @returnHandle of the matching rule
>>* @retvalODP_PMR_INVAL on failure
>> @@ -258,7 +266,10 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term,
>>   odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term,
>>const void *val1,
>>const void *val2,
>> -  uint32_t val_sz);
>> +  uint32_t val_sz,
>> +  odp_cos_t src_cos,
>> +  odp_cos_t dst_cos);
>> +
>>   /**
>>* Invalidate a packet match rule and vacate its resources
>>*
>> @@ -270,30 +281,20 @@ odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term,
>>   int odp_pmr_destroy(odp_pmr_t pmr_id);
>>
>>   /**
>> - * Apply a PMR to a pktio to assign a CoS.
>> - *
>> - * @param[in]  pmr_id  PMR to be activated
>> - * @param[in]  src_pktio   pktio to which this PMR is to be applied
>> - * @param[in]  dst_cos CoS to be assigned by this PMR
>> + * Apply a initial CoS to a pktio.
>>*
>> - * @retval 0 on success
>> - * @retval <0 on failure
>> - */
>> -int odp_pktio_pmr_cos(odp_pmr_t pmr_id,
>> - odp_pktio_t src_pktio, odp_cos_t dst_cos);
>> -
>> -/**
>> - * Cascade a PMR to refine packets from one CoS to another.
>> + * This is the initial CoS that is assigned to packets arriving
>> + * from the 'pktio' channel, that may later be changed by any
>> + * Packet matching rules (PMRs) that hae the 'pktio_cos' assigned
>> + * as its 'src_cos'.
>>*
>> - * @param[in]  pmr_id  PMR to be activated
>> - * @param[in]  src_cos CoS to be filtered
>> - *

[lng-odp] [PATCHv3] example: ODP classifier example

[bala . manoharan]

From: Balasubramanian Manoharan 

ODP Classifier example

This programs gets pmr rules as command-line parameter and configures the 
classification engine
in the system.

This initial version supports the following
* ODP_PMR_SIP_ADDR pmr term
* PMR term MATCH and RANGE type
* Multiple PMR rule can be set on a single pktio interface with different 
queues associated to each PMR rule
* Automatically configures a default queue and provides statistics for the same

Signed-off-by: Balasubramanian Manoharan 
---
V3: Incorporates review comments from Mike and Maxim
Adds a timeout variable to configure the time in seconds for classifier example 
to run.

 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/classifier/Makefile.am  |  10 +
 example/classifier/odp_classifier.c | 820 
 4 files changed, 832 insertions(+), 1 deletion(-)
 create mode 100644 example/classifier/Makefile.am
 create mode 100644 example/classifier/odp_classifier.c

diff --git a/configure.ac b/configure.ac
index 78ff245..d20bad2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
 AC_CONFIG_FILES([Makefile
 doc/Makefile
 example/Makefile
+example/classifier/Makefile
 example/generator/Makefile
 example/ipsec/Makefile
 example/packet/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 6bb4f5c..353f397 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec packet timer
+SUBDIRS = classifier generator ipsec packet timer
diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
new file mode 100644
index 000..938f094
--- /dev/null
+++ b/example/classifier/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_classifier
+odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
+odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_classifier_SOURCES = odp_classifier.c
diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
new file mode 100644
index 000..85b6e00
--- /dev/null
+++ b/example/classifier/odp_classifier.c
@@ -0,0 +1,820 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** @def MAX_WORKERS
+ * @brief Maximum number of worker threads
+ */
+#define MAX_WORKERS32
+
+/** @def SHM_PKT_POOL_SIZE
+ * @brief Size of the shared memory block
+ */
+#define SHM_PKT_POOL_SIZE  (512*2048)
+
+/** @def SHM_PKT_POOL_BUF_SIZE
+ * @brief Buffer size of the packet pool buffer
+ */
+#define SHM_PKT_POOL_BUF_SIZE  1856
+
+/** @def MAX_PMR_COUNT
+ * @brief Maximum number of Classification Policy
+ */
+#define MAX_PMR_COUNT  8
+
+/** @def DISPLAY_STRING_LEN
+ * @brief Length of string used to display term value
+ */
+#define DISPLAY_STRING_LEN 32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   odp_queue_t queue;  /**< Associated queue handle */
+   odp_cos_t cos;  /**< Associated cos handle */
+   odp_pmr_t pmr;  /**< Associated pmr handle */
+   odp_atomic_u64_t packet_count;  /**< count of received packets */
+   odp_pmr_term_e term;/**< odp pmr term value */
+   char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
+   odp_pmr_match_type_e match_type;/**< pmr match type */
+   int val_sz; /**< size of the pmr term */
+   union {
+   struct {
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } match;
+   struct  {
+   uint32_t val1;  /**< pmr term start range */
+   uint32_t val2;  /**< pmr term end range */
+   } range;
+   };
+   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
+   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
+} global_statistics;
+
+typedef struct {
+   global_statistics stats[MAX_PMR_COUNT];
+   int policy_count;   /**< global policy count */
+   int appl_mode;  /**< application mode */
+   odp_atomic_u64_t total_packets; /**< total received packets */
+   int cpu_count;  /**< Number of CPUs to use */
+   uint32_t time;  /**< Number of seconds to run */
+   char *if_name;  /**< pointer to interface names */
+} appl_args_t;
+
+enum packet_m

Re: [lng-odp] [PATCHv3] example: ODP classifier example

[Bala Manoharan]

On 21 April 2015 at 16:57, Maxim Uvarov  wrote:
> Bala, one more comment. Please do parsing arguments before odp init.
>
>
> About this code Mike found that it will be abort if you do not run it under
> root due to
> unable do raw socket operations.
>
>
> pktio = odp_pktio_open(dev, pool);
> if (pktio == ODP_PKTIO_INVALID)
> EXAMPLE_ABORT("pktio create failed for %s\n", dev);


The abort in this case if because the EXAMPLE_ABORT macro implements
abort() function instead of exit(EXIT_FAILURE)
IMO calling exit is better as this causes a graceful shutdown of the
system. In any case I believe it is better for the application to call
this macro and the macro definition can implement exit() instead of
abort()

>
> I tried "loop" application starts well. But needed some traffic so that loop
> is no good fit.
> I think it's better to exit from this app with some return code and add
> small note to
> Usage that for linux-generic user has to be root to open real devices in raw
> mode.

I believe the reason we added this macro EXAMPLE_ABORT was to be used
by the application in the scenario when it wants to terminate the
function so that the macro can be modified by different platforms.
We can call usage() to display the usage here but I am against calling
exit() directly in the application
>
> Thanks,
> Maxim.
>
>
> On 04/16/15 14:41, bala.manoha...@linaro.org wrote:
>>
>> From: Balasubramanian Manoharan 
>>
>> ODP Classifier example
>>
>> This programs gets pmr rules as command-line parameter and configures the
>> classification engine
>> in the system.
>>
>> This initial version supports the following
>> * ODP_PMR_SIP_ADDR pmr term
>> * PMR term MATCH and RANGE type
>> * Multiple PMR rule can be set on a single pktio interface with different
>> queues associated to each PMR rule
>> * Automatically configures a default queue and provides statistics for the
>> same
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> V3: Incorporates review comments from Mike and Maxim
>> Adds a timeout variable to configure the time in seconds for classifier
>> example to run.
>>
>>   configure.ac|   1 +
>>   example/Makefile.am |   2 +-
>>   example/classifier/Makefile.am  |  10 +
>>   example/classifier/odp_classifier.c | 820
>> 
>>   4 files changed, 832 insertions(+), 1 deletion(-)
>>   create mode 100644 example/classifier/Makefile.am
>>   create mode 100644 example/classifier/odp_classifier.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78ff245..d20bad2 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
>>   AC_CONFIG_FILES([Makefile
>>  doc/Makefile
>>  example/Makefile
>> +example/classifier/Makefile
>>  example/generator/Makefile
>>  example/ipsec/Makefile
>>  example/packet/Makefile
>> diff --git a/example/Makefile.am b/example/Makefile.am
>> index 6bb4f5c..353f397 100644
>> --- a/example/Makefile.am
>> +++ b/example/Makefile.am
>> @@ -1 +1 @@
>> -SUBDIRS = generator ipsec packet timer
>> +SUBDIRS = classifier generator ipsec packet timer
>> diff --git a/example/classifier/Makefile.am
>> b/example/classifier/Makefile.am
>> new file mode 100644
>> index 000..938f094
>> --- /dev/null
>> +++ b/example/classifier/Makefile.am
>> @@ -0,0 +1,10 @@
>> +include $(top_srcdir)/example/Makefile.inc
>> +
>> +bin_PROGRAMS = odp_classifier
>> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
>> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
>> +
>> +noinst_HEADERS = \
>> + $(top_srcdir)/example/example_debug.h
>> +
>> +dist_odp_classifier_SOURCES = odp_classifier.c
>> diff --git a/example/classifier/odp_classifier.c
>> b/example/classifier/odp_classifier.c
>> new file mode 100644
>> index 000..85b6e00
>> --- /dev/null
>> +++ b/example/classifier/odp_classifier.c
>> @@ -0,0 +1,820 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/** @def MAX_WORKERS
>> + * @brief Maximum number of worker threads
>> + */
>> +#define MAX_WORKERS32
>> +
>> +/** @def SHM_PKT_POOL_SIZE
>> + * @brief Size of the shared memory block
>> + */
>> +#define SHM_PKT_POOL_SIZE  (512*2048)
>> +
>> +/** @def SHM_PKT_POOL_BUF_SIZE
>> + * @brief Buffer size of the packet pool buffer
>> + */
>> +#define SHM_PKT_POOL_BUF_SIZE  1856
>> +
>> +/** @def MAX_PMR_COUNT
>> + * @brief Maximum number of Classification Policy
>> + */
>> +#define MAX_PMR_COUNT  8
>> +
>> +/** @def DISPLAY_STRING_LEN
>> + * @brief Length of string used to display term value
>> + */
>> +#define DISPLAY_STRING_LEN 32
>> +
>> +/** Get rid of p

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

[Bala Manoharan]

On 21 April 2015 at 18:15, Ola Liljedahl  wrote:
> On 21 April 2015 at 14:26, Maxim Uvarov  wrote:
>>
>> On 04/21/15 15:01, Bill Fischofer wrote:
>>>
>>> Behavior is undefined if rules are ambiguous. Consider the following
>>> rules:
>>>
>>> protocol == UDP --> CoS A
>>> port == 1234 --> CoS B
>>>
>>> What happens if a UDP packet for port 1234 arrives? Answer: undefined.
>>
>>
>>
>> Isn't pmr created one by one to the table? And first match will return Cos
>> A in that case.
>
> Since we are having this discussion, it is obvious that we need a definition
> of the ODP classification that cannot be misunderstood or misinterpreted.
> Probably a formal definition. Or do everyone here agree that the (current)
> linux-generic implementation can serve as *the* definition?

Shouldn't we use the classification design document as the definition
of classification and the linux-generic implementation can be used as
a reference and not "the" definition.

Regards,
Bala
>
>
>
>>
>>
>> Maxim.
>>
>>> The result may be either CoS A or CoS B.
>>>
>>> A better rule set would be:
>>>
>>> protocol == UDP --> CoS A
>>>
>>> CoS A && port == 1234 --> CoS B
>>>
>>> Now this is unambiguous.  UDP packets go to CoS A unless they also
>>> specify port 1234, in which case they go to CoS B.
>>>
>>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl >> > wrote:
>>>
>>> On 20 April 2015 at 21:49, Bill Fischofer
>>> mailto:bill.fischo...@linaro.org>> wrote:
>>>
>>> Classification is a collaboration between the implementation
>>> and the application. It is the application's responsibility to
>>> write unambiguous classification rules and it is the
>>> implementation's job to perform the match as efficiently and
>>> as specifically as possible.
>>>
>>> What should an implementation do if the classification rules are
>>> ambiguous? E.g. if partial matches (of different partially
>>> overlapping rules) use different CoS? Is this an error already
>>> when creating the PMR rules?
>>>
>>> -- Ola
>>>
>>>
>>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
>>> mailto:ola.liljed...@linaro.org>>
>>> wrote:
>>>
>>> On 17 April 2015 at 22:55, Rosenboim, Leonid
>>> >> > wrote:
>>>
>>>
>>> Guys,
>>>
>>> There are several versions of the Classifier API
>>> document floating in Google docs, here is one such copy:
>>>
>>>
>>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
>>>
>>> Here is a different perspective on what PMR and COS
>>> mean,  perhaps in terms of an abstract hardware
>>> implementation:
>>>
>>> CoS is a meta-data field assigned to each packet as it
>>> traverses the classifier pipe-line.
>>>
>>> A packet is assigned an initial CoS by the pktio port
>>> which received it.
>>>
>>> Then, the packet is compared multiple times against a
>>> set of rules, and as it is common with TCAMs, each
>>> comparisons happens against all rules in parallel.
>>>
>>> Each rule has two values to match: 1. the current CoS
>>> meta-data field; and 2. a certain packet header field
>>> (value with a mask).
>>> If both these values match, the packet met-data CoS
>>> field is changed (Action taken) with the destination
>>> CoS of the matching rule.
>>>
>>> It is assumed that up to one such rule has matched.
>>>
>>> If a rule has matched, CoS has changed, the process
>>> continues one more time.
>>>
>>> If NO MATCH occured, the classification process is
>>> finished, and the packet is delivered in accordance to
>>> the current CoS (i.e. the last matching rule or the
>>> pktio default CoS if the first rule match failed).
>>>
>>> So partial matches are valid. Is this what we want, e.g.
>>> from application point of view and from HW point of view?
>>>
>>> Is partial matches what is commonly supported by HW
>>> classifiers?
>>>
>>> A classifier which supports these longest prefix matches
>>> can easily implement perfect matching (all partial matches
>>> just specify the "default" CoS). But a classifier which
>>> only supports perfect matching cannot directly support
>>> partial matches. I assume you would have to internally
>>> create rules/patterns for all (relevant) partial matches
>>> as well. The implementation can find all relevant partial
>>> matches (prefix rules which spec

Re: [lng-odp] [PATCHv3] example: ODP classifier example

[Bala Manoharan]

On 21 April 2015 at 16:57, Maxim Uvarov  wrote:
> Bala, one more comment. Please do parsing arguments before odp init.

Sorry missed this comment. parsing argument uses odp shared memory and
we cannot call it before odp init() function.

Regards,
Bala
>
>
> About this code Mike found that it will be abort if you do not run it under
> root due to
> unable do raw socket operations.
>
>
> pktio = odp_pktio_open(dev, pool);
> if (pktio == ODP_PKTIO_INVALID)
> EXAMPLE_ABORT("pktio create failed for %s\n", dev);
>
> I tried "loop" application starts well. But needed some traffic so that loop
> is no good fit.
> I think it's better to exit from this app with some return code and add
> small note to
> Usage that for linux-generic user has to be root to open real devices in raw
> mode.
>
> Thanks,
> Maxim.
>
>
> On 04/16/15 14:41, bala.manoha...@linaro.org wrote:
>>
>> From: Balasubramanian Manoharan 
>>
>> ODP Classifier example
>>
>> This programs gets pmr rules as command-line parameter and configures the
>> classification engine
>> in the system.
>>
>> This initial version supports the following
>> * ODP_PMR_SIP_ADDR pmr term
>> * PMR term MATCH and RANGE type
>> * Multiple PMR rule can be set on a single pktio interface with different
>> queues associated to each PMR rule
>> * Automatically configures a default queue and provides statistics for the
>> same
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> V3: Incorporates review comments from Mike and Maxim
>> Adds a timeout variable to configure the time in seconds for classifier
>> example to run.
>>
>>   configure.ac|   1 +
>>   example/Makefile.am |   2 +-
>>   example/classifier/Makefile.am  |  10 +
>>   example/classifier/odp_classifier.c | 820
>> 
>>   4 files changed, 832 insertions(+), 1 deletion(-)
>>   create mode 100644 example/classifier/Makefile.am
>>   create mode 100644 example/classifier/odp_classifier.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78ff245..d20bad2 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
>>   AC_CONFIG_FILES([Makefile
>>  doc/Makefile
>>  example/Makefile
>> +example/classifier/Makefile
>>  example/generator/Makefile
>>  example/ipsec/Makefile
>>  example/packet/Makefile
>> diff --git a/example/Makefile.am b/example/Makefile.am
>> index 6bb4f5c..353f397 100644
>> --- a/example/Makefile.am
>> +++ b/example/Makefile.am
>> @@ -1 +1 @@
>> -SUBDIRS = generator ipsec packet timer
>> +SUBDIRS = classifier generator ipsec packet timer
>> diff --git a/example/classifier/Makefile.am
>> b/example/classifier/Makefile.am
>> new file mode 100644
>> index 000..938f094
>> --- /dev/null
>> +++ b/example/classifier/Makefile.am
>> @@ -0,0 +1,10 @@
>> +include $(top_srcdir)/example/Makefile.inc
>> +
>> +bin_PROGRAMS = odp_classifier
>> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
>> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
>> +
>> +noinst_HEADERS = \
>> + $(top_srcdir)/example/example_debug.h
>> +
>> +dist_odp_classifier_SOURCES = odp_classifier.c
>> diff --git a/example/classifier/odp_classifier.c
>> b/example/classifier/odp_classifier.c
>> new file mode 100644
>> index 000..85b6e00
>> --- /dev/null
>> +++ b/example/classifier/odp_classifier.c
>> @@ -0,0 +1,820 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/** @def MAX_WORKERS
>> + * @brief Maximum number of worker threads
>> + */
>> +#define MAX_WORKERS32
>> +
>> +/** @def SHM_PKT_POOL_SIZE
>> + * @brief Size of the shared memory block
>> + */
>> +#define SHM_PKT_POOL_SIZE  (512*2048)
>> +
>> +/** @def SHM_PKT_POOL_BUF_SIZE
>> + * @brief Buffer size of the packet pool buffer
>> + */
>> +#define SHM_PKT_POOL_BUF_SIZE  1856
>> +
>> +/** @def MAX_PMR_COUNT
>> + * @brief Maximum number of Classification Policy
>> + */
>> +#define MAX_PMR_COUNT  8
>> +
>> +/** @def DISPLAY_STRING_LEN
>> + * @brief Length of string used to display term value
>> + */
>> +#define DISPLAY_STRING_LEN 32
>> +
>> +/** Get rid of path in filename - only for unix-type paths using '/' */
>> +#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
>> +   strrchr((file_name), '/') + 1 : (file_name))
>> +
>> +typedef struct {
>> +   odp_queue_t queue;  /**< Associated queue handle */
>> +   odp_cos_t cos;  /**< Associated cos handle */
>> +   odp_pmr_t pmr;  /**< Associated pmr handle */
>> +   odp_atomic_u64_t packet_count;  /**< count of received packets */
>> +   odp_pmr_term_e term

Re: [lng-odp] [PATCHv3] example: ODP classifier example

[Bala Manoharan]

On 23 April 2015 at 15:13, Maxim Uvarov  wrote:
> On 04/23/15 12:08, Bala Manoharan wrote:
>>
>> On 21 April 2015 at 16:57, Maxim Uvarov  wrote:
>>>
>>> Bala, one more comment. Please do parsing arguments before odp init.
>>
>> Sorry missed this comment. parsing argument uses odp shared memory and
>> we cannot call it before odp init() function.
>>
>> Regards,
>> Bala
>
>
> I see that Suart also uses shared memory for argument. But why not malloc()
> ?

This parse argument data needs to be shared across cores and
bare-metal case we cannot use malloc() and share the data with other
cores.

Regards,
Bala
>
> Maxim.
>
>
>>>
>>> About this code Mike found that it will be abort if you do not run it
>>> under
>>> root due to
>>> unable do raw socket operations.
>>>
>>>
>>>  pktio = odp_pktio_open(dev, pool);
>>>  if (pktio == ODP_PKTIO_INVALID)
>>>  EXAMPLE_ABORT("pktio create failed for %s\n", dev);
>>>
>>> I tried "loop" application starts well. But needed some traffic so that
>>> loop
>>> is no good fit.
>>> I think it's better to exit from this app with some return code and add
>>> small note to
>>> Usage that for linux-generic user has to be root to open real devices in
>>> raw
>>> mode.
>>>
>>> Thanks,
>>> Maxim.
>>>
>>>
>>> On 04/16/15 14:41, bala.manoha...@linaro.org wrote:
>>>>
>>>> From: Balasubramanian Manoharan 
>>>>
>>>> ODP Classifier example
>>>>
>>>> This programs gets pmr rules as command-line parameter and configures
>>>> the
>>>> classification engine
>>>> in the system.
>>>>
>>>> This initial version supports the following
>>>> * ODP_PMR_SIP_ADDR pmr term
>>>> * PMR term MATCH and RANGE type
>>>> * Multiple PMR rule can be set on a single pktio interface with
>>>> different
>>>> queues associated to each PMR rule
>>>> * Automatically configures a default queue and provides statistics for
>>>> the
>>>> same
>>>>
>>>> Signed-off-by: Balasubramanian Manoharan 
>>>> ---
>>>> V3: Incorporates review comments from Mike and Maxim
>>>> Adds a timeout variable to configure the time in seconds for classifier
>>>> example to run.
>>>>
>>>>configure.ac|   1 +
>>>>example/Makefile.am |   2 +-
>>>>example/classifier/Makefile.am  |  10 +
>>>>example/classifier/odp_classifier.c | 820
>>>> 
>>>>4 files changed, 832 insertions(+), 1 deletion(-)
>>>>create mode 100644 example/classifier/Makefile.am
>>>>create mode 100644 example/classifier/odp_classifier.c
>>>>
>>>> diff --git a/configure.ac b/configure.ac
>>>> index 78ff245..d20bad2 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
>>>>AC_CONFIG_FILES([Makefile
>>>>   doc/Makefile
>>>>   example/Makefile
>>>> +example/classifier/Makefile
>>>>   example/generator/Makefile
>>>>   example/ipsec/Makefile
>>>>   example/packet/Makefile
>>>> diff --git a/example/Makefile.am b/example/Makefile.am
>>>> index 6bb4f5c..353f397 100644
>>>> --- a/example/Makefile.am
>>>> +++ b/example/Makefile.am
>>>> @@ -1 +1 @@
>>>> -SUBDIRS = generator ipsec packet timer
>>>> +SUBDIRS = classifier generator ipsec packet timer
>>>> diff --git a/example/classifier/Makefile.am
>>>> b/example/classifier/Makefile.am
>>>> new file mode 100644
>>>> index 000..938f094
>>>> --- /dev/null
>>>> +++ b/example/classifier/Makefile.am
>>>> @@ -0,0 +1,10 @@
>>>> +include $(top_srcdir)/example/Makefile.inc
>>>> +
>>>> +bin_PROGRAMS = odp_classifier
>>>> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
>>>> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
>>>> +
>>>> +noinst_HEADERS = \
>>>> + $(top_srcdir)/example/example_debug

[lng-odp] [PATCHv4] example: ODP classifier example

[bala . manoharan]

From: Balasubramanian Manoharan 

ODP Classifier example

This programs gets pmr rules as command-line parameter and configures the 
classification engine
in the system.

This initial version supports the following
* ODP_PMR_SIP_ADDR pmr term
* PMR term MATCH and RANGE type
* Multiple PMR rule can be set on a single pktio interface with different 
queues associated to each PMR rule
* Automatically configures a default queue and provides statistics for the same
* Prints statistics interms of the number of packets dispatched to each queue

Signed-off-by: Balasubramanian Manoharan 
---
v4: Incorporates review comments from Mike and Ola
 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/classifier/.gitignore   |   1 +
 example/classifier/Makefile.am  |  10 +
 example/classifier/odp_classifier.c | 835 
 5 files changed, 848 insertions(+), 1 deletion(-)
 create mode 100644 example/classifier/.gitignore
 create mode 100644 example/classifier/Makefile.am
 create mode 100644 example/classifier/odp_classifier.c

diff --git a/configure.ac b/configure.ac
index 78ff245..d20bad2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
 AC_CONFIG_FILES([Makefile
 doc/Makefile
 example/Makefile
+example/classifier/Makefile
 example/generator/Makefile
 example/ipsec/Makefile
 example/packet/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 6bb4f5c..353f397 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec packet timer
+SUBDIRS = classifier generator ipsec packet timer
diff --git a/example/classifier/.gitignore b/example/classifier/.gitignore
new file mode 100644
index 000..a356d48
--- /dev/null
+++ b/example/classifier/.gitignore
@@ -0,0 +1 @@
+odp_classifier
diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
new file mode 100644
index 000..938f094
--- /dev/null
+++ b/example/classifier/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_classifier
+odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
+odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_classifier_SOURCES = odp_classifier.c
diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
new file mode 100644
index 000..cf53565
--- /dev/null
+++ b/example/classifier/odp_classifier.c
@@ -0,0 +1,835 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** @def MAX_WORKERS
+ * @brief Maximum number of worker threads
+ */
+#define MAX_WORKERS32
+
+/** @def SHM_PKT_POOL_SIZE
+ * @brief Size of the shared memory block
+ */
+#define SHM_PKT_POOL_SIZE  (512*2048)
+
+/** @def SHM_PKT_POOL_BUF_SIZE
+ * @brief Buffer size of the packet pool buffer
+ */
+#define SHM_PKT_POOL_BUF_SIZE  1856
+
+/** @def MAX_PMR_COUNT
+ * @brief Maximum number of Classification Policy
+ */
+#define MAX_PMR_COUNT  8
+
+/** @def DISPLAY_STRING_LEN
+ * @brief Length of string used to display term value
+ */
+#define DISPLAY_STRING_LEN 32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   odp_queue_t queue;  /**< Associated queue handle */
+   odp_cos_t cos;  /**< Associated cos handle */
+   odp_pmr_t pmr;  /**< Associated pmr handle */
+   odp_atomic_u64_t packet_count;  /**< count of received packets */
+   odp_pmr_term_e term;/**< odp pmr term value */
+   char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
+   odp_pmr_match_type_e match_type;/**< pmr match type */
+   int val_sz; /**< size of the pmr term */
+   union {
+   struct {
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } match;
+   struct  {
+   uint32_t val1;  /**< pmr term start range */
+   uint32_t val2;  /**< pmr term end range */
+   } range;
+   };
+   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
+   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
+} global_statistics;
+
+typedef struct {
+   global_statistics stats[MAX_PMR_COUNT];
+   int policy_count;   /**< global policy count */
+   int appl_mode;  /**< application mode */
+ 

Re: [lng-odp] [PATCH] validation: odp_pool: add double destroy

[Bala Manoharan]

On 23 April 2015 at 16:56, Maxim Uvarov  wrote:
> On 04/23/15 13:09, Taras Kondratiuk wrote:
>>
>> On 04/22/2015 08:54 PM, Maxim Uvarov wrote:
>>>
>>> On 04/22/15 19:06, Ciprian Barbu wrote:

 On Wed, Apr 22, 2015 at 5:13 PM, Maxim Uvarov
  wrote:
>
> On 04/22/15 15:53, Bill Fischofer wrote:
>>
>> It does that, but as Taras points out there is a race condition.  If
>> one
>> thread does an odp_pool_destroy() and it succeeds, another thread
>> could do
>> an odp_pool_create() before the second odp_pool_destroy() and get
>> the same
>> pool handle which would then be deleted by the second
>> odp_pool_destroy()
>> call.
>>
> odp_pool_destroy() should hold lock inside it. (i.e. it already does
> that).

 The scenario is not about a race condition on create/delete, it's
 actually even simpler:

 th1: lock -> create_pool -> unlock
 th1: lock -> destroy_pool -> unlock
 th2: lock -> create_pool -> unlock
 th1: lock -> destroy_pool -> unlock
>>>
>>> Ok, but it's not undefined behavior. If you work with threads you should
>>> know what you do.
>>>
>>> So behavior is: destroy function fails if pool already destroyed.
>>>
>>> I still think that Mikes test is valid. It's single threaded application
>>> with very exact case.
>>> Analogy for example:
>>> char *a = malloc(10);
>>> a[5] = 1;
>>>
>>> On your logic it has to be undefined behavior due to some other thread
>>> can free or malloc with different size.
>>
>> This in not a valid analogy. Should be something like this.
>>
>> char *a = malloc(10);
>> free(a);
>> free(a); /* Here you may free a block which is allocated again by another
>> thread */
>
> Yes, and glibc will warn if you do double free. I still think that it's
> reasonable to accept that patch.

I agree with Taras. pool handle will map to a specific buffer
management hardware in the system and the value of odp_pool_t will be
the same even if the same pool gets allocated to a different process.

Regards,
Bala
>
> Maxim.
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/3] test: classification: add missing init of atomic variable

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

On 24 April 2015 at 19:23, Nicolas Morey-Chaisemartin  wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin 
> ---
>  test/validation/classification/odp_classification_tests.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/test/validation/classification/odp_classification_tests.c 
> b/test/validation/classification/odp_classification_tests.c
> index 1bf080f..b44bc62 100644
> --- a/test/validation/classification/odp_classification_tests.c
> +++ b/test/validation/classification/odp_classification_tests.c
> @@ -319,6 +319,7 @@ int classification_tests_init(void)
> for (i = 0; i < CLS_ENTRIES; i++)
> queue_list[i] = ODP_QUEUE_INVALID;
>
> +   odp_atomic_init_u32(&seq, 0);
> return 0;
>  }
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 2/3] linux-generic: packet_io: init l2 and l3 cos table spinlocks

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

On 24 April 2015 at 19:23, Nicolas Morey-Chaisemartin  wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin 
> ---
>  platform/linux-generic/odp_packet_io.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/platform/linux-generic/odp_packet_io.c 
> b/platform/linux-generic/odp_packet_io.c
> index cfe5b71..f16685d 100644
> --- a/platform/linux-generic/odp_packet_io.c
> +++ b/platform/linux-generic/odp_packet_io.c
> @@ -61,6 +61,8 @@ int odp_pktio_init_global(void)
>
> odp_spinlock_init(&pktio_entry->s.lock);
> odp_spinlock_init(&pktio_entry->s.cls.lock);
> +   odp_spinlock_init(&pktio_entry->s.cls.l2_cos_table.lock);
> +   odp_spinlock_init(&pktio_entry->s.cls.l3_cos_table.lock);
>
> pktio_entry_ptr[id - 1] = pktio_entry;
> /* Create a default output queue for each pktio resource */
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse mode

[Bala Manoharan]

Hi,

We can optimize the odp_packet_parse_flags_t in the following way to
handle the layered approach for parsing

+typedef struct odp_packet_parse_flags_t {

+   uint32_t eth:1;   /**< See odp_packet_has_eth() */
+   uint32_t jumbo:1; /**< See odp_packet_has_jumbo() */
+   uint32_t vlan:1;  /**< See odp_packet_has_vlan() */
+   uint32_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
+   uint32_t arp:1;   /**< See odp_packet_has_arp() */
+   uint32_t ipv4:1;  /**< See odp_packet_has_ipv4() */
+   uint32_t ipv6:1;  /**< See odp_packet_has_ipv6() */
+   uint32_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
+   uint32_t ipopt:1; /**< See odp_packet_has_ipopt() */
+   uint32_t ipsec:1; /**< See odp_packet_has_ipsec() */
+   uint32_t udp:1;   /**< See odp_packet_has_udp() */
+   uint32_t tcp:1;   /**< See odp_packet_has_tcp() */
+   uint32_t sctp:1;  /**< See odp_packet_has_sctp() */
+   uint32_t icmp:1;  /**< See odp_packet_has_icmp() */
+
+   uint32_t _reserved1:18; /**< Reserved. Do not use. */
+} odp_packet_parse_flags_t;

On 29 April 2015 at 12:15, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
> It's (v2) on the list (since last Thu):
>
> [lng-odp] [API-NEXT PATCH v2 4/5] api: packet_io: added parse mode
>
>
> -Petri
>
>
>> -Original Message-
>> From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
>> Sent: Tuesday, April 28, 2015 9:17 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse
>> mode
>>
>>
>>
>> On 28/04/15 08:09, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > Hi Zoltan,
>> >
>> > You should implement the latest version of the patch, which has only
>> ALL/NONE defined. We can leave SELECTED for later.
>> Ok, but where is that version? I could only find this one.
>>
>> >
>> > Briefly about SELECTED. The idea is that the application lists all
>> odp_packet_has_xxx() calls that it will call during packet processing.
>> Implementation can use that information to optimize parser functionality,
>> if it can. So, application is not telling to implementation what to do or
>> how to do it, but what information application is expecting from packets.
>> If application lies (indicates that it will not call xxx, but still calls
>> it), results are undefined.
>> >
>> > -Petri
>> >
>> >
>> >> -Original Message-
>> >> From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
>> >> Sent: Monday, April 27, 2015 8:29 PM
>> >> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
>> >> Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse
>> >> mode
>> >>
>> >>
>> >>
>> >> On 20/04/15 13:10, Petri Savolainen wrote:
>> >>> Application can indicate which packet parsing results it is
>> >>> interested in (all, none or selected).
>> >>>
>> >>> Signed-off-by: Petri Savolainen 
>> >>> ---
>> >>>include/odp/api/packet_flags.h | 26 ++
>> >>>include/odp/api/packet_io.h| 19 +++
>> >>>2 files changed, 45 insertions(+)
>> >>>
>> >>> diff --git a/include/odp/api/packet_flags.h
>> >> b/include/odp/api/packet_flags.h
>> >>> index bfbcc94..9444fdc 100644
>> >>> --- a/include/odp/api/packet_flags.h
>> >>> +++ b/include/odp/api/packet_flags.h
>> >>> @@ -26,6 +26,32 @@ extern "C" {
>> >>> *  @{
>> >>> */
>> >>>
>> >>> +
>> >>> +/**
>> >>> + * Packet input parsing flags
>> >>> + *
>> >>> + * Each flag represents a parser output. See parser output functions
>> >> for
>> >>> + * details.
>> >>
>> >> Now that I implement this for linux-generic, I realized this is
>> >> ambiguous: does disabling a lower layer's parsing means that the parser
>> >> stops looking into upper layers? Even if their parsing is enabled?
>> >> E.g. if (jumbo == 0 && ipv4 == 1), we won't parse the ethernet header
>> if
>> >> it's a jumbo frame, that's fine. But do we continue to look into the
>> >> rest of the packet for the IPv4 header?
>> >> I would say no, but it should be mentioned here explicitly.
>> >>
>> >>> + */
>> >>> +typedef struct odp_packet_parse_flags_t {
>> >>> + uint32_t eth:1;   /**< See odp_packet_has_eth() */
>> >>> + uint32_t jumbo:1; /**< See odp_packet_has_jumbo() */
>> >>> + uint32_t vlan:1;  /**< See odp_packet_has_vlan() */
>> >>> + uint32_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
>> >>> + uint32_t arp:1;   /**< See odp_packet_has_arp() */
>> >>> + uint32_t ipv4:1;  /**< See odp_packet_has_ipv4() */
>> >>> + uint32_t ipv6:1;  /**< See odp_packet_has_ipv6() */
>> >>> + uint32_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
>> >>> + uint32_t ipopt:1; /**< See odp_packet_has_ipopt() */
>> >>> + uint32_t ipsec:1; /**< See odp_packet_has_ipsec() */
>> >>> + uint32_t udp:1;   /**< See odp_packet_has_udp() */
>> >>> + uint32_t tcp:1;   /**< See odp_packet_has_tcp() */
>> >>> + u

Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse mode

[Bala Manoharan]

Hi,

Sorry I clicked send way too early in the previous mail :)

We can optimize the odp_packet_parse_flags_t struct to support
both  layered parsing and individual parsing by the following way.

I believe this might be useful for both application and implementation.

typedef struct odp_packet_parse_flags_t {
union {
uint8_t l2_all;
struct {
   uint8_t eth:1;   /**< See odp_packet_has_eth() */
   uint8_t jumbo:1; /**< See odp_packet_has_jumbo() */
   uint8_t vlan:1;  /**< See odp_packet_has_vlan() */
   uint8_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
};
};
union {
uint8_t l2_all;
struct {
uint8_t arp:1;   /**< See odp_packet_has_arp() */
uint8_t ipv4:1;  /**< See odp_packet_has_ipv4() */
uint8_t ipv6:1;  /**< See odp_packet_has_ipv6() */
uint8_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
uint8_t ipopt:1; /**< See odp_packet_has_ipopt() */
uint8_t ipsec:1; /**< See odp_packet_has_ipsec() */
};
};
union {
uint8_t l4_all;
struct {
uint8_t udp:1;   /**< See odp_packet_has_udp() */
uint8_t tcp:1;   /**< See odp_packet_has_tcp() */
uint8_t sctp:1;  /**< See odp_packet_has_sctp() */
uint8_t icmp:1;  /**< See odp_packet_has_icmp() */
};
};
} odp_packet_parse_flags_t;

Regards,
Bala

On 29 April 2015 at 12:46, Bala Manoharan  wrote:
> Hi,
>
> We can optimize the odp_packet_parse_flags_t in the following way to
> handle the layered approach for parsing
>
> +typedef struct odp_packet_parse_flags_t {
>
> +   uint32_t eth:1;   /**< See odp_packet_has_eth() */
> +   uint32_t jumbo:1; /**< See odp_packet_has_jumbo() */
> +   uint32_t vlan:1;  /**< See odp_packet_has_vlan() */
> +   uint32_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
> +   uint32_t arp:1;   /**< See odp_packet_has_arp() */
> +   uint32_t ipv4:1;  /**< See odp_packet_has_ipv4() */
> +   uint32_t ipv6:1;  /**< See odp_packet_has_ipv6() */
> +   uint32_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
> +   uint32_t ipopt:1; /**< See odp_packet_has_ipopt() */
> +   uint32_t ipsec:1; /**< See odp_packet_has_ipsec() */
> +   uint32_t udp:1;   /**< See odp_packet_has_udp() */
> +   uint32_t tcp:1;   /**< See odp_packet_has_tcp() */
> +   uint32_t sctp:1;  /**< See odp_packet_has_sctp() */
> +   uint32_t icmp:1;  /**< See odp_packet_has_icmp() */
> +
> +   uint32_t _reserved1:18; /**< Reserved. Do not use. */
> +} odp_packet_parse_flags_t;
>
> On 29 April 2015 at 12:15, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>> It's (v2) on the list (since last Thu):
>>
>> [lng-odp] [API-NEXT PATCH v2 4/5] api: packet_io: added parse mode
>>
>>
>> -Petri
>>
>>
>>> -Original Message-
>>> From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
>>> Sent: Tuesday, April 28, 2015 9:17 PM
>>> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse
>>> mode
>>>
>>>
>>>
>>> On 28/04/15 08:09, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>> > Hi Zoltan,
>>> >
>>> > You should implement the latest version of the patch, which has only
>>> ALL/NONE defined. We can leave SELECTED for later.
>>> Ok, but where is that version? I could only find this one.
>>>
>>> >
>>> > Briefly about SELECTED. The idea is that the application lists all
>>> odp_packet_has_xxx() calls that it will call during packet processing.
>>> Implementation can use that information to optimize parser functionality,
>>> if it can. So, application is not telling to implementation what to do or
>>> how to do it, but what information application is expecting from packets.
>>> If application lies (indicates that it will not call xxx, but still calls
>>> it), results are undefined.
>>> >
>>> > -Petri
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
>>> >> Sent: Monday, April 27, 2015 8:29 PM
>>> >> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
>>> >> Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse
>>

Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse mode

[Bala Manoharan]

On 29 April 2015 at 13:24, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
> Hi,
>
> Possibly. Although, grouping adds struct complexity, so there should be some 
> benefit on doing that. I was going to add union "all" there, but decided to 
> leave it out since unnamed structs/unions are not defined in C99, so the both 
> the union and the bit field struct inside would have to be named (for strict 
> C99 compatibility). I think API needs to be strictly C99, other code 
> (linux-generic and tests) can relax a bit from that requirement.
>
> Instead of unions, I'd defined a set of (inline) functions:
>
> // Check if all L2 flags are set
> // @return non-zero when all L2 level flags are set
> int odp_packet_parse_all_l2(const odp_packet_parse_flags_t *flags);

One minor query on the above function,
So when application calls the above function what will be the value of "flags"?
 will it have only l2 flags set or will have other layer flags also set?

Regards,
Bala

>
> // Set all L2 flags
> void odp_packet_parse_all_l2_set(odp_packet_parse_flags_t *flags);
>
> ...
>
>
> Also I think the implementation would not only check levels, but for specific 
> flags - especially those ones it does not have HW support. E.g. an 
> implementation may have everything else filled in by HW, but "sctp" or "tcp 
> options" flags. If the application does not ask for those, the implementation 
> is good to go as-is. If the application asks those, the implementation has to 
> choose a strategy to fill in those one way or another.
>
>
> -Petri
>
>> -Original Message-
>> From: ext Bala Manoharan [mailto:bala.manoha...@linaro.org]
>> Sent: Wednesday, April 29, 2015 10:25 AM
>> To: Savolainen, Petri (Nokia - FI/Espoo)
>> Cc: ext Zoltan Kiss; lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse
>> mode
>>
>> Hi,
>>
>> Sorry I clicked send way too early in the previous mail :)
>>
>> We can optimize the odp_packet_parse_flags_t struct to support
>> both  layered parsing and individual parsing by the following way.
>>
>> I believe this might be useful for both application and implementation.
>>
>> typedef struct odp_packet_parse_flags_t {
>> union {
>> uint8_t l2_all;
>> struct {
>>uint8_t eth:1;   /**< See odp_packet_has_eth() */
>>uint8_t jumbo:1; /**< See odp_packet_has_jumbo() */
>>uint8_t vlan:1;  /**< See odp_packet_has_vlan() */
>>uint8_t vlan_qinq:1; /**< See
>> odp_packet_has_vlan_qinq() */
>> };
>> };
>> union {
>> uint8_t l2_all;
>> struct {
>> uint8_t arp:1;   /**< See odp_packet_has_arp() */
>> uint8_t ipv4:1;  /**< See odp_packet_has_ipv4() */
>> uint8_t ipv6:1;  /**< See odp_packet_has_ipv6() */
>> uint8_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
>> uint8_t ipopt:1; /**< See odp_packet_has_ipopt() */
>> uint8_t ipsec:1; /**< See odp_packet_has_ipsec() */
>> };
>> };
>> union {
>> uint8_t l4_all;
>> struct {
>> uint8_t udp:1;   /**< See odp_packet_has_udp() */
>> uint8_t tcp:1;   /**< See odp_packet_has_tcp() */
>> uint8_t sctp:1;  /**< See odp_packet_has_sctp() */
>> uint8_t icmp:1;  /**< See odp_packet_has_icmp() */
>> };
>> };
>> } odp_packet_parse_flags_t;
>>
>> Regards,
>> Bala
>>
>> On 29 April 2015 at 12:46, Bala Manoharan 
>> wrote:
>> > Hi,
>> >
>> > We can optimize the odp_packet_parse_flags_t in the following way to
>> > handle the layered approach for parsing
>> >
>> > +typedef struct odp_packet_parse_flags_t {
>> >
>> > +   uint32_t eth:1;   /**< See odp_packet_has_eth() */
>> > +   uint32_t jumbo:1; /**< See odp_packet_has_jumbo() */
>> > +   uint32_t vlan:1;  /**< See odp_packet_has_vlan() */
>> > +   uint32_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
>> > +   uint32_t arp:1;   /**< See odp_packet_has_arp() */
>> > +   uint32_t ipv4:1;  /**< See odp_packet_has_ipv4() */
>> > +   uint32_t ipv6:1;  /**< See odp_packet_has_ipv6() */
>> > +   uint32_t ipfrag:1;/**< See odp_packet

[lng-odp] [PATCHv1] example: classifier: remove odp_pmr_create_range() support

[bala . manoharan]

From: Balasubramanian Manoharan 

This patch removes support for odp_pmr_create_range() function 
in the classifier example application.

Signed-off-by: Balasubramanian Manoharan 
---
 example/classifier/odp_classifier.c | 106 ++--
 1 file changed, 29 insertions(+), 77 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index cf53565..d78eb7b 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -52,22 +52,15 @@ typedef struct {
odp_cos_t cos;  /**< Associated cos handle */
odp_pmr_t pmr;  /**< Associated pmr handle */
odp_atomic_u64_t packet_count;  /**< count of received packets */
-   odp_pmr_term_e term;/**< odp pmr term value */
char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
-   odp_pmr_match_type_e match_type;/**< pmr match type */
int val_sz; /**< size of the pmr term */
-   union {
-   struct {
-   uint32_t val;   /**< pmr term value */
-   uint32_t mask;  /**< pmr term mask */
-   } match;
-   struct  {
-   uint32_t val1;  /**< pmr term start range */
-   uint32_t val2;  /**< pmr term end range */
-   } range;
-   };
-   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
-   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
+   struct {
+   odp_pmr_term_e term;/**< odp pmr term value */
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } rule;
+   char value[DISPLAY_STRING_LEN]; /**< Display string for value */
+   char mask[DISPLAY_STRING_LEN];  /**< Display string for mask */
 } global_statistics;
 
 typedef struct {
@@ -114,18 +107,14 @@ void print_cls_statistics(appl_args_t *args)
printf("\n");
printf("CONFIGURATION\n");
printf("\n");
-   printf("QUEUE\tMATCH\tVALUE1\t\tVALUE2\n");
+   printf("QUEUE\tVALUE\t\tMASK\n");
for (i = 0; i < 40; i++)
printf("-");
printf("\n");
for (i = 0; i < args->policy_count - 1; i++) {
printf("%s\t", args->stats[i].queue_name);
-   if (args->stats[i].match_type == ODP_PMR_MASK)
-   printf("MATCH\t");
-   else
-   printf("RANGE\t");
-   printf("%s\t", args->stats[i].value1);
-   printf("%s\n", args->stats[i].value2);
+   printf("%s\t", args->stats[i].value);
+   printf("%s\n", args->stats[i].mask);
}
printf("\n");
printf("RECEIVED PACKETS\n");
@@ -357,17 +346,10 @@ static void configure_cos_queue(odp_pktio_t pktio, 
appl_args_t *args)
sprintf(cos_name, "CoS%s", stats->queue_name);
stats->cos = odp_cos_create(cos_name);
 
-   if (stats->match_type == ODP_PMR_MASK) {
-   stats->pmr = odp_pmr_create_match(stats->term,
-   &stats->match.val,
-   &stats->match.mask,
-   stats->val_sz);
-   } else {
-   stats->pmr = odp_pmr_create_range(stats->term,
-   &stats->range.val1,
-   &stats->range.val2,
-   stats->val_sz);
-   }
+   stats->pmr = odp_pmr_create(stats->rule.term,
+   &stats->rule.val,
+   &stats->rule.mask,
+   stats->val_sz);
qparam.sched.prio = i % odp_schedule_num_prio();
qparam.sched.sync = ODP_SCHED_SYNC_NONE;
qparam.sched.group = ODP_SCHED_GROUP_ALL;
@@ -614,39 +596,18 @@ static int parse_pmr_policy(appl_args_t *appl_args, char 
*argv[], char *optarg)
EXAMPLE_ERR("Invalid ODP_PMR_TERM string\n");
exit(EXIT_FAILURE);
}
-   stats[policy_count].term = term;
-   /* PMR RANGE vs MATCH */
-   token = strtok(NULL, ":");
-   if (0 == strcasecmp(token, "range")) {
-   stats[policy_count].match_type = ODP_PMR_RANGE;
-   } else if (0 == strcasecmp(token, "match")) {
-   stats[policy_count].match_type = ODP_PMR_MASK;
-   } else {
-   usage(argv[0]);
-   exit(EXIT_FAILURE);
-   }
+   stats[policy_count].rule.term = term;
 
/* PMR value */
switch (term)   {
case ODP_PMR_SIP_ADDR:
-   if (stats[policy_count].match_type == ODP_PMR_MASK) {
-   token = strtok(NULL, ":");
-   strcpy(stats[p

Re: [lng-odp] [PATCHv1] example: classifier: remove odp_pmr_create_range() support

[Bala Manoharan]

This patch needs to be applied on the master branch after the
following patches are merged from api-next to master branch.

api: classification: remove odp_pmr_create_range() function definition
linux-generic: classification: remove odp_pmr_create_range() function
implementation.
validation: remove test case for odp_pmr_create_range() function

Regards,
Bala

On 29 April 2015 at 14:04,   wrote:
> From: Balasubramanian Manoharan 
>
> This patch removes support for odp_pmr_create_range() function
> in the classifier example application.
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  example/classifier/odp_classifier.c | 106 
> ++--
>  1 file changed, 29 insertions(+), 77 deletions(-)
>
> diff --git a/example/classifier/odp_classifier.c 
> b/example/classifier/odp_classifier.c
> index cf53565..d78eb7b 100644
> --- a/example/classifier/odp_classifier.c
> +++ b/example/classifier/odp_classifier.c
> @@ -52,22 +52,15 @@ typedef struct {
> odp_cos_t cos;  /**< Associated cos handle */
> odp_pmr_t pmr;  /**< Associated pmr handle */
> odp_atomic_u64_t packet_count;  /**< count of received packets */
> -   odp_pmr_term_e term;/**< odp pmr term value */
> char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
> -   odp_pmr_match_type_e match_type;/**< pmr match type */
> int val_sz; /**< size of the pmr term */
> -   union {
> -   struct {
> -   uint32_t val;   /**< pmr term value */
> -   uint32_t mask;  /**< pmr term mask */
> -   } match;
> -   struct  {
> -   uint32_t val1;  /**< pmr term start range */
> -   uint32_t val2;  /**< pmr term end range */
> -   } range;
> -   };
> -   char value1[DISPLAY_STRING_LEN];/**< Display string1 */
> -   char value2[DISPLAY_STRING_LEN];/**< Display string2 */
> +   struct {
> +   odp_pmr_term_e term;/**< odp pmr term value */
> +   uint32_t val;   /**< pmr term value */
> +   uint32_t mask;  /**< pmr term mask */
> +   } rule;
> +   char value[DISPLAY_STRING_LEN]; /**< Display string for value */
> +   char mask[DISPLAY_STRING_LEN];  /**< Display string for mask */
>  } global_statistics;
>
>  typedef struct {
> @@ -114,18 +107,14 @@ void print_cls_statistics(appl_args_t *args)
> printf("\n");
> printf("CONFIGURATION\n");
> printf("\n");
> -   printf("QUEUE\tMATCH\tVALUE1\t\tVALUE2\n");
> +   printf("QUEUE\tVALUE\t\tMASK\n");
> for (i = 0; i < 40; i++)
> printf("-");
> printf("\n");
> for (i = 0; i < args->policy_count - 1; i++) {
> printf("%s\t", args->stats[i].queue_name);
> -   if (args->stats[i].match_type == ODP_PMR_MASK)
> -   printf("MATCH\t");
> -   else
> -   printf("RANGE\t");
> -   printf("%s\t", args->stats[i].value1);
> -   printf("%s\n", args->stats[i].value2);
> +   printf("%s\t", args->stats[i].value);
> +   printf("%s\n", args->stats[i].mask);
> }
> printf("\n");
> printf("RECEIVED PACKETS\n");
> @@ -357,17 +346,10 @@ static void configure_cos_queue(odp_pktio_t pktio, 
> appl_args_t *args)
> sprintf(cos_name, "CoS%s", stats->queue_name);
> stats->cos = odp_cos_create(cos_name);
>
> -   if (stats->match_type == ODP_PMR_MASK) {
> -   stats->pmr = odp_pmr_create_match(stats->term,
> -   &stats->match.val,
> -   &stats->match.mask,
> -   stats->val_sz);
> -   } else {
> -   stats->pmr = odp_pmr_create_range(stats->term,
> -   &stats->range.val1,
> -   &stats->range.val2,
> -   stats->val_sz);
> -   }
> +   stats->pmr = odp_pmr_create(stats->rule.term,
> +   &stats->rule.val,
> +   &stats->rule.mask,
> +   stats->val_sz);
> qparam.sched.prio = i % odp_schedule_num_prio();
> qparam.sched.sync = ODP_SCHED_SYNC_NONE;
> qparam.sched.group = ODP_SCHED_GROUP_ALL;
> @@ -614,39 +596,18 @@ static int parse_pmr_policy(appl_args_t *appl_args, 
> char *argv[], char *optarg)
> EXAMPLE_ERR("Invalid ODP_PMR_TERM string\n");
> exit(EXIT_FAILURE);
> }
> -   stats[policy_count].term = term;
> -   /* PMR RANGE vs MATCH */
> -   token = strtok(NULL, ":");
> -   if (0 == str

Re: [lng-odp] Query on classification's rules ordering

[Bala Manoharan]

Hi,

Cos configured using PMR takes precedence over CoS configured using L2 and
L3 priority and QoS values.

Among L2 and L3 values, odp_cos_with_l3_qos() function contains a boolean
"L3_precedence" which indicates whether L2 or L3 priority value takes
precedence.

Hope this helps,
Bala

On 6 May 2015 at 15:59, Sunil Kumar Kori  wrote:

>  Hello,
>
>
>
> I was looking into the ODP v1.0 classification APIs.  I have doubt
> regarding the order of rules to be applied on a single pktio. Following is
> the scenario:
>
> 1.   Pktio is configured with l2 priority using
> *odp_cos_with_l2_priority*
>
> 2.   Pktio is configured with l3 qos using *odp_cos_with_l3_qos*
>
> 3.   Pktio is configured with pmr using *odp_pktio_pmr_cos*
>
> Assume a packet arrives which satisfy all the 3 rules (as given above)
> then what should be the expected order/precedence of rules?
>
>
>
> Regards
>
> Sunil Kumar
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] Query on classification's rules ordering

[Bala Manoharan]

Hi Sunil,

In classification the responsibility is with the application as NOT to
configure conflicting PMR rules which match at the same level in the pktio
interface. Since from the implementation stand point it is not possible to
provide precedence when multiple PMR rules are matching at the same level.

Pls note that there is a provision in classification API to create chained
PMR rule set see odp_cos_pmr_cos().

Regards,
Bala

On 7 May 2015 at 15:24, Sunil Kumar Kori  wrote:

>  Hello Bala,
>
>
>
> Thanks for the clarification of below query.
>
>  In the continuation, ODP classification document
> http://www.opendataplane.org/wp-content/uploads/2014/01/ODP_Classifier.docx.pdf
> describes that precedence is undetermined in case of multiple pmr matched
> with received frame.  See description of *odp_pktio_pmr_cos*.
>
>
>
> This behavior can cause problem when any application will be running over
> the different classifier and each classifier can have its own way to
> distribute the frame when multiple rules will be matched.
>
> Please provide some input on this.
>
>
>
> Regards
>
> Sunil Kumar
>
>
>
> *From:* Bala Manoharan [mailto:bala.manoha...@linaro.org]
> *Sent:* Wednesday, May 06, 2015 4:51 PM
> *To:* Kori Sunil-B42948
> *Cc:* lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] Query on classification's rules ordering
>
>
>
> Hi,
>
>
>
> Cos configured using PMR takes precedence over CoS configured using L2 and
> L3 priority and QoS values.
>
>
>
> Among L2 and L3 values, odp_cos_with_l3_qos() function contains a boolean
> "L3_precedence" which indicates whether L2 or L3 priority value takes
> precedence.
>
>
>
> Hope this helps,
>
> Bala
>
>
>
> On 6 May 2015 at 15:59, Sunil Kumar Kori  wrote:
>
>  Hello,
>
>
>
> I was looking into the ODP v1.0 classification APIs.  I have doubt
> regarding the order of rules to be applied on a single pktio. Following is
> the scenario:
>
> 1.   Pktio is configured with l2 priority using
> *odp_cos_with_l2_priority*
>
> 2.   Pktio is configured with l3 qos using *odp_cos_with_l3_qos*
>
> 3.   Pktio is configured with pmr using *odp_pktio_pmr_cos*
>
> Assume a packet arrives which satisfy all the 3 rules (as given above)
> then what should be the expected order/precedence of rules?
>
>
>
> Regards
>
> Sunil Kumar
>
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/3] example: classifier: remove extra local init

[Bala Manoharan]

Reviewed-by: Balasubramanian Manoharan 

IMO, we can add additional information in odph_linux_pthread_create()
header file documentation that this function is expected to call
odp_init_local() for the thread it creates. Current documentation only says
the following

/**
 * Creates and launches pthreads
 *
 * Creates, pins and launches threads to separate CPU's based on the
cpumask.
 *
 * @param thread_tblThread table
 * @param mask  CPU mask
 * @param start_routine Thread start function
 * @param arg   Thread argument
 */
void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
   const odp_cpumask_t *mask,
   void *(*start_routine) (void *), void *arg);

Regards,
Bala

On 7 May 2015 at 17:04, Petri Savolainen  wrote:

> Worker threads are created with odph_linux_pthread_create()
> which calls odp_local_init() before entering the function.
>
> Signed-off-by: Petri Savolainen 
> ---
>  example/classifier/odp_classifier.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/example/classifier/odp_classifier.c
> b/example/classifier/odp_classifier.c
> index d78eb7b..35d9684 100644
> --- a/example/classifier/odp_classifier.c
> +++ b/example/classifier/odp_classifier.c
> @@ -249,13 +249,6 @@ static void *pktio_receive_thread(void *arg)
> appl_args_t *appl = (appl_args_t *)arg;
> global_statistics *stats;
>
> -
> -   /* Init this thread */
> -   if (odp_init_local()) {
> -   EXAMPLE_ERR("ODP thread local init failed.\n");
> -   exit(EXIT_FAILURE);
> -   }
> -
> /* Loop packets */
> for (;;) {
> odp_pktio_t pktio_tmp;
> --
> 2.4.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] Query regarding sequence number update in IPSEC application

[Bala Manoharan]

IMO, using atomic variable instead of atomic queues will work for this
Ipsec example use-case as in this case the critical section is required
only for updating the sequence number but in a generic use-case the
atomicity should be protected over "a region of code" which the application
wants to be executed in the ingress-order.
If HWs are capable we should add additional APIs for scheduler based
locking which can be used by application incase the critical section is
small enough that going through scheduler will cause a performance impact.

Regards,
Bala

On 12 May 2015 at 17:31, Ola Liljedahl  wrote:

> Yes the seqno counter is a shared resource and the atomic_fetch_and_add
> will eventually become a bottleneck for per-SA throughput. But one could
> hope that it should scale better than using atomic queues although this
> depends on the actual microarchitecture.
>
> Freescale PPC has "decorated storage", can't it be used for
> atomic_fetch_and_add()?
> ARMv8.1 has support for "far atomics" which are supposed to scale better
> (again depends on the actual implementation).
>
> On 12 May 2015 at 13:47, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>> Atomic increment performance gets worse by increasing the number of cores
>> -
>> see
>> https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2015.01.31a.pdf
>> - chapter 5) for some measurements on a conventional Intel machine.
>> It may be possible for this overhead to become bigger than the one
>> associated with the atomic queue.
>>
>> Alex
>>
>> On 12 May 2015 at 14:20, Ola Liljedahl  wrote:
>>
>>> I think it should be OK to use ordered queues instead of atomic queues,
>>> e.g. for sequence number allocation (which will need an atomic variable to
>>> hold the seqno counter). Packet ingress order will be maintained but might
>>> not always correspond to sequence number order. This is not a problem a the
>>> sliding window in the replay protection will take care of that, the sliding
>>> window could be hundreds of entries (sequence numbers) large (each will
>>> only take one bit). Packet ingress order is the important characteristic
>>> that must be maintained. The IPsec sequence number is not used for packet
>>> ordering and order restoration, it is only used for replay protection.
>>>
>>> Someone with a platform which supports both ordered and atomic
>>> scheduling could benchmark both designs and see how performance scales when
>>> using ordered queues (and that atomic fetch_and_add) for some relevant
>>> traffic patterns.
>>>
>>> On 8 May 2015 at 13:53, Bill Fischofer 
>>> wrote:
>>>
 Jerrin,

 Can you propose such a set of APIs for further discussion?  This would
 be good to discuss at the Tuesday call.

 Thanks.

 Bill

 On Fri, May 8, 2015 at 12:07 AM, Jacob, Jerin <
 jerin.ja...@caviumnetworks.com> wrote:

>
> I agree with Ola here on preserving the ingress order.
> However, I have experienced same performance issue as Nikhil pointed
> out
> (atomic queues have too much overhead for short critical section)
>
> I am not sure about any other HW but Cavium has support for
> introducing the critical section while maintain the ingress order as a
> HW scheduler feature.
>
> IMO, if such support is available in other HW then
> odp_schedule_ordered_lock()/unlock()
> kind of API will solve the performance issue for the need for short
> critical section in ordered flow.
>
> /Jerin.
>
>
> From: lng-odp  on behalf of Ola
> Liljedahl 
> Sent: Thursday, May 7, 2015 9:06 PM
> To: nikhil.agar...@freescale.com
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Query regarding sequence number update in IPSEC
> application
>
>
> Using atomic queues will preserve the ingress order when allocating
> and assigning the sequence number. Also you don't need to use an expensive
> atomic operation for updating the sequence number as the atomic queue and
> scheduling will provide mutual  exclusion.
>
>
> If the packets that require a sequence number came from parallel or
> ordered queues, there would be no guarantee that the sequence numbers 
> would
> be allocated in packet (ingress) order. Just using an atomic operation
> (e.g. fetch_and_add or similar) only  guarantees proper update of the
> sequence number variable, not any specific ordering.
>
>
> If you are ready to trade absolute "correctness" for performance, you
> could use ordered or may even parallel (questionable for other reasons)
> queues and then allocate the sequence number using an atomic 
> fetch_and_add.
> Sometimes packets  egress order will then not match the sequence number
> order (for a flow/SA). For IPSec, this might affect the replay window 
> check
> & update at the receiving end but as the replay protection uses a slid

Re: [lng-odp] Query regarding sequence number update in IPSEC application

[Bala Manoharan]

On 12 May 2015 at 18:06, Ola Liljedahl  wrote:
>
> On 12 May 2015 at 14:28, Bala Manoharan  wrote:
>>
>> IMO, using atomic variable instead of atomic queues will work for this Ipsec 
>> example use-case as in this case the critical section is required only for 
>> updating the sequence number but in a generic use-case the atomicity should 
>> be protected over "a region of code" which the application wants to be 
>> executed in the ingress-order.
>
> Isn't this the atomic queues/scheduling of ODP (and several SoC's)?

Yes. But atomic queue switching is currently only through scheduler
and it involves scheduler overhead.

>
>
>>
>> If HWs are capable we should add additional APIs for scheduler based locking 
>> which can be used by application incase the critical section is small enough 
>> that going through scheduler will cause a performance impact.
>
> Isn't there a "release atomic scheduling" function? A CPU processing stage 
> can start out atomic (HW provided mutual exclusion) but convert into 
> "ordered" scheduling when the mutual exclusion is no longer necessary. Or 
> this missing from the ODP API today?

"release atomic scheduling" only talks from "Atomic --> ordered"
scenario, I believe the scenario here dictates
"Ordered --> Atomic --> Ordered" sequence. Currently this sequence
goes through the scheduler and the intent is to avoid scheduler
overhead.

Regards,
Bala

>
>
>>
>> Regards,
>> Bala
>>
>> On 12 May 2015 at 17:31, Ola Liljedahl  wrote:
>>>
>>> Yes the seqno counter is a shared resource and the atomic_fetch_and_add 
>>> will eventually become a bottleneck for per-SA throughput. But one could 
>>> hope that it should scale better than using atomic queues although this 
>>> depends on the actual microarchitecture.
>>>
>>> Freescale PPC has "decorated storage", can't it be used for 
>>> atomic_fetch_and_add()?
>>> ARMv8.1 has support for "far atomics" which are supposed to scale better 
>>> (again depends on the actual implementation).
>>>
>>> On 12 May 2015 at 13:47, Alexandru Badicioiu 
>>>  wrote:
>>>>
>>>> Atomic increment performance gets worse by increasing the number of cores -
>>>> see 
>>>> https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2015.01.31a.pdf
>>>>  - chapter 5) for some measurements on a conventional Intel machine.
>>>> It may be possible for this overhead to become bigger than the one 
>>>> associated with the atomic queue.
>>>>
>>>> Alex
>>>>
>>>> On 12 May 2015 at 14:20, Ola Liljedahl  wrote:
>>>>>
>>>>> I think it should be OK to use ordered queues instead of atomic queues, 
>>>>> e.g. for sequence number allocation (which will need an atomic variable 
>>>>> to hold the seqno counter). Packet ingress order will be maintained but 
>>>>> might not always correspond to sequence number order. This is not a 
>>>>> problem a the sliding window in the replay protection will take care of 
>>>>> that, the sliding window could be hundreds of entries (sequence numbers) 
>>>>> large (each will only take one bit). Packet ingress order is the 
>>>>> important characteristic that must be maintained. The IPsec sequence 
>>>>> number is not used for packet ordering and order restoration, it is only 
>>>>> used for replay protection.
>>>>>
>>>>> Someone with a platform which supports both ordered and atomic scheduling 
>>>>> could benchmark both designs and see how performance scales when using 
>>>>> ordered queues (and that atomic fetch_and_add) for some relevant traffic 
>>>>> patterns.
>>>>>
>>>>> On 8 May 2015 at 13:53, Bill Fischofer  wrote:
>>>>>>
>>>>>> Jerrin,
>>>>>>
>>>>>> Can you propose such a set of APIs for further discussion?  This would 
>>>>>> be good to discuss at the Tuesday call.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>> On Fri, May 8, 2015 at 12:07 AM, Jacob, Jerin 
>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>> I agree with Ola here on preserving the ingress order.
>>>>>>> However, I have exper

Re: [lng-odp] Classification: APIs deferred from ODP v1.0

[Bala Manoharan]

Hi,

These APIs are in the list of changes required for classification and
will be introduced  in the next version of ODP.

Regards,
Bala

On 13 May 2015 at 15:12, Agrawal Hemant  wrote:
> HI,
> What is the plan to re-introduce the flow signature based 
> distribution APIs in next version of ODP?
>
> Regards,
> Hemant
>
> -Original Message-
> From: lng-odp-boun...@lists.linaro.org 
> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Balasubramanian 
> Manoharan
> Sent: Wednesday, November 26, 2014 3:29 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH v2] Classification: APIs deferred from ODP v1.0
>
> This patch removes Classification APIs which have been deferred from ODP v1.0 
> The following is the list of the deferred APIs
> * odp_cos_set_queue_group
> * odp_cos_set_pool
> * odp_cos_set_headroom
> * odp_cos_flow_set
> * odp_cos_flow_is_set
> * odp_cos_class_flow_signature
> * odp_cos_port_flow_signature
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
> V2: This patch is modified as independantly compilable unit  
> .../linux-generic/include/api/odp_classification.h | 106 +
>  platform/linux-generic/odp_classification.c|  48 +-
>  2 files changed, 8 insertions(+), 146 deletions(-)
>
> diff --git a/platform/linux-generic/include/api/odp_classification.h 
> b/platform/linux-generic/include/api/odp_classification.h
> index cc5d84a..64ad73f 100644
> --- a/platform/linux-generic/include/api/odp_classification.h
> +++ b/platform/linux-generic/include/api/odp_classification.h
> @@ -48,6 +48,9 @@ typedef uint32_t odp_flowsig_t;  */
>  #define ODP_COS_INVALID((odp_cos_t)~0)
>
> +/** Maximum ClassOfService name length in chars */ #define
> +ODP_COS_NAME_LEN 32
> +
>  /**
>   * Class-of-service packet drop policies
>   */
> @@ -110,33 +113,6 @@ int odp_cos_destroy(odp_cos_t cos_id);  int 
> odp_cos_set_queue(odp_cos_t cos_id, odp_queue_t queue_id);
>
>  /**
> - * Assign a homogenous queue-group to a class-of-service.
> - *
> - * @param[in]  cos_id  class-of-service instance
> - * @param[in]  queue_group_id  Identifier of the queue group to receive 
> packets
> - * associated with this class of service.
> - *
> - * @return 0 on success, -1 on error.
> - */
> -int odp_cos_set_queue_group(odp_cos_t cos_id,
> -   odp_queue_group_t queue_group_id);
> -
> -/**
> - * Assign packet buffer pool for specific class-of-service
> - *
> - * @param[in]  cos_id  class-of-service instance.
> - * @param[in]  pool_id Buffer pool identifier where all packet 
> buffers
> - * will be sourced to store packet that
> - * belong to this class of service.
> - *
> - * @return 0 on success, -1 on error.
> - *
> - * @note Optional.
> - */
> -int odp_cos_set_pool(odp_cos_t cos_id, odp_buffer_pool_t pool_id);
> -
> -
> -/**
>   * Assign packet drop policy for specific class-of-service
>   *
>   * @param[in]  cos_id  class-of-service instance.
> @@ -203,21 +179,6 @@ int odp_pktio_set_skip(odp_pktio_t pktio_in, size_t 
> offset);  int odp_pktio_set_headroom(odp_pktio_t pktio_in, size_t headroom);
>
>  /**
> - * Specify per-cos buffer headroom
> - *
> - * @param[in]  cos_id  Class-of-service instance
> - * @param[in]  headroomNumber of bytes of space preceding packet
> - * data to reserve for use as headroom.
> - * Must not exceed the implementation
> - * defined ODP_PACKET_MAX_HEADROOM.
> - *
> - * @return 0 on success, -1 on error.
> - *
> - * @note Optional.
> - */
> -int odp_cos_set_headroom(odp_cos_t cos_id, size_t headroom);
> -
> -/**
>   * Request to override per-port class of service
>   * based on Layer-2 priority field if present.
>   *
> @@ -263,60 +224,6 @@ int odp_cos_with_l3_qos(odp_pktio_t pktio_in,  typedef 
> uint16_t odp_cos_flow_set_t;
>
>  /**
> - * Set a member of the flow signature fields data set
> - */
> -static inline
> -odp_cos_flow_set_t odp_cos_flow_set(odp_cos_flow_set_t set,
> -   odp_cos_hdr_flow_fields_e field)
> -{
> -   return set | (1U << field);
> -}
> -
> -/**
> - * Test a member of the flow signature fields data set
> - */
> -static inline bool
> -odp_cos_flow_is_set(odp_cos_flow_set_t set, odp_cos_hdr_flow_fields_e field) 
> -{
> -   return (set & (1U << field)) != 0;
> -}
> -
> -/**
> - * Set up set of headers used to calculate a flow signature
> - * based on class-of-service.
> - *
> - * @param[in]  cos_id  Class of service instance identifier
> - * @param[in]  req_data_setRequested data-set for
> - * flow signature calculation
> - *
> - * @return Data-set that was successfully applied.
> - * All-zeros data set