Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: packet: allow access to packet RSS hash values

[Santosh Shukla]

On 20 August 2015 at 16:23, Jerin Jacob  wrote:
> On Thu, Aug 20, 2015 at 03:30:23PM +0530, Santosh Shukla wrote:
>> On 20 August 2015 at 14:48, Balasubramanian Manoharan
>>  wrote:
>> >
>> >
>> > On Sunday 16 August 2015 06:14 PM, Santosh Shukla wrote:
>> >>
>> >> On 15 August 2015 at 00:12, Zoltan Kiss  wrote:
>> >>>
>> >>> Applications can read the computed hash (if any) and set it if they
>> >>> changed the packet headers or if the platform haven't calculated the
>> >>> hash.
>> >>>
>> >>> Signed-off-by: Zoltan Kiss 
>> >>> ---
>> >>> v2:
>> >>> - focus on RSS hash only
>> >>> - use setter/getter's
>> >>>
>> >>> v3:
>> >>> - do not mention pointers
>> >>> - add a note
>> >>> - add new patches for implementation and test
>> >>>
>> >>>   include/odp/api/packet.h | 30 ++
>> >>>   1 file changed, 30 insertions(+)
>> >>>
>> >>> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
>> >>> index 3a454b5..1ae24bc 100644
>> >>> --- a/include/odp/api/packet.h
>> >>> +++ b/include/odp/api/packet.h
>> >>> @@ -48,6 +48,11 @@ extern "C" {
>> >>>* Invalid packet segment
>> >>>*/
>> >>>
>> >>> +/**
>> >>> + * @def ODP_PACKET_RSS_INVALID
>> >>> + * RSS hash is not set
>> >>> + */
>> >>> +
>> >>>   /*
>> >>>*
>> >>>* Alloc and free
>> >>> @@ -605,6 +610,31 @@ uint32_t odp_packet_l4_offset(odp_packet_t pkt);
>> >>>   int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t offset);
>> >>>
>> >>>   /**
>> >>> + * RSS hash value
>> >>> + *
>> >>> + * Returns the RSS hash stored for the packet.
>> >>> + *
>> >>> + * @param  pkt  Packet handle
>> >>> + *
>> >>> + * @return  Hash value
>> >>> + * @retval ODP_PACKET_RSS_INVALID if RSS hash is not set.
>> >>> + */
>> >>> +uint32_t odp_packet_rss_hash(odp_packet_t pkt);
>> >>> +
>> >>> +/**
>> >>> + * Set RSS hash value
>> >>> + *
>> >>> + * Store the RSS hash for the packet.
>> >>> + *
>> >>> + * @param  pkt  Packet handle
>> >>> + * @param  rss_hash Hash value to set
>> >>> + *
>> >>> + * @note If the application changes the packet header, it might want to
>> >>> + * recalculate this value and set it.
>> >>> + */
>> >>> +void odp_packet_rss_hash_set(odp_packet_t pkt, uint32_t rss_hash);
>> >
>> > Can this use-case be handled by calling
>> > odp_packet_generate_rss_hash(odp_packet_t pkt) function where the rss gets
>> > generated by the implementation rather than being set from application 
>> > using
>> > odp_packet_set_rss_hash() function?
>> >
>>
>> Bala, As we discussed and in summary for rest; Considering ovs example
>> : ovs uses sw based rss_hash only when HW not supporting rss Or HW
>> generated rss is zero.
>>
>> hash = packet_get_hash(packet);
>> if (OVS_UNLIKELY(!hash)) {
>> hash = miniflow_hash_5tuple(mf, 0);
>> packet_set_hash(packet, hash);
>> }
>> return hash;
>>
>> and rss_hash generation is inside ovs dp_packet (middle  layer), It is
>
> How about following change in OVS plarform specific packet_get_hash code.
> odp_packet_rss_hash_set
> kind of interface wont fit correctly in octeon  platform as hash
> identifier used by hardware in subsequent HW based queue operations
>
> static inline uint32_t
> packet_get_hash(struct dp_packet *p)
> {
> #ifdef DPDK_NETDEV
> return p->mbuf.hash.rss;
> #else
> #ifdef ODP_NETDEV
> unit32_t hash;
> hash = odp_packet_rss_hash(p->odp_pkt);
> if (OVS_UNLIKELY(!hash)
> hash = odp_packet_generate_rss_hash(p->odp_pkt);
> return hash;
> #endif
> return p->rss_hash;
> #endif
> }
>

Trying to understand your api definition;
odp_packet_rss_hash() -> to get rss
and
odp_packet_generate_rss_hash() -> generate rss from where :  sw or hw?
In either case, your trying to generate non-ze

Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: packet: allow access to packet RSS hash values

[Santosh Shukla]

On 20 August 2015 at 14:48, Balasubramanian Manoharan
 wrote:
>
>
> On Sunday 16 August 2015 06:14 PM, Santosh Shukla wrote:
>>
>> On 15 August 2015 at 00:12, Zoltan Kiss  wrote:
>>>
>>> Applications can read the computed hash (if any) and set it if they
>>> changed the packet headers or if the platform haven't calculated the
>>> hash.
>>>
>>> Signed-off-by: Zoltan Kiss 
>>> ---
>>> v2:
>>> - focus on RSS hash only
>>> - use setter/getter's
>>>
>>> v3:
>>> - do not mention pointers
>>> - add a note
>>> - add new patches for implementation and test
>>>
>>>   include/odp/api/packet.h | 30 ++
>>>   1 file changed, 30 insertions(+)
>>>
>>> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
>>> index 3a454b5..1ae24bc 100644
>>> --- a/include/odp/api/packet.h
>>> +++ b/include/odp/api/packet.h
>>> @@ -48,6 +48,11 @@ extern "C" {
>>>* Invalid packet segment
>>>*/
>>>
>>> +/**
>>> + * @def ODP_PACKET_RSS_INVALID
>>> + * RSS hash is not set
>>> + */
>>> +
>>>   /*
>>>*
>>>* Alloc and free
>>> @@ -605,6 +610,31 @@ uint32_t odp_packet_l4_offset(odp_packet_t pkt);
>>>   int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t offset);
>>>
>>>   /**
>>> + * RSS hash value
>>> + *
>>> + * Returns the RSS hash stored for the packet.
>>> + *
>>> + * @param  pkt  Packet handle
>>> + *
>>> + * @return  Hash value
>>> + * @retval ODP_PACKET_RSS_INVALID if RSS hash is not set.
>>> + */
>>> +uint32_t odp_packet_rss_hash(odp_packet_t pkt);
>>> +
>>> +/**
>>> + * Set RSS hash value
>>> + *
>>> + * Store the RSS hash for the packet.
>>> + *
>>> + * @param  pkt  Packet handle
>>> + * @param  rss_hash Hash value to set
>>> + *
>>> + * @note If the application changes the packet header, it might want to
>>> + * recalculate this value and set it.
>>> + */
>>> +void odp_packet_rss_hash_set(odp_packet_t pkt, uint32_t rss_hash);
>
> Can this use-case be handled by calling
> odp_packet_generate_rss_hash(odp_packet_t pkt) function where the rss gets
> generated by the implementation rather than being set from application using
> odp_packet_set_rss_hash() function?
>

Bala, As we discussed and in summary for rest; Considering ovs example
: ovs uses sw based rss_hash only when HW not supporting rss Or HW
generated rss is zero.

hash = packet_get_hash(packet);
if (OVS_UNLIKELY(!hash)) {
hash = miniflow_hash_5tuple(mf, 0);
packet_set_hash(packet, hash);
}
return hash;

and rss_hash generation is inside ovs dp_packet (middle  layer), It is
with in ovs implementation, Not exposed to application layer, so
application won't need to generate rss / update, so no possibility of
rss mis-match /corruption.

> Regards,
> Bala
>
>>> +
>>> +/**
>>>* Tests if packet is segmented
>>>*
>>>* @param pkt  Packet handle
>>> --
>>
>> Reviewed-by : Santosh Shukla 
>>
>>> 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 v3 2/3] linux-generic: packet: implement RSS hash support

[Santosh Shukla]

On 17 August 2015 at 14:09, Zoltan Kiss  wrote:
>
>
> On 17/08/15 07:24, Maxim Uvarov wrote:
>>
>> On 08/14/15 21:42, Zoltan Kiss wrote:
>>>
>>> This platform doesn't compute it, packet_init set it to 0, which happens
>>> to be ODP_PACKET_RSS_INVALID.
>>>
>>> Signed-off-by: Zoltan Kiss 
>>> ---
>>>   platform/linux-generic/include/odp/plat/packet_types.h |  2 ++
>>>   platform/linux-generic/include/odp_packet_internal.h   |  1 +
>>>   platform/linux-generic/odp_packet.c| 14
>>> ++
>>>   3 files changed, 17 insertions(+)
>>>
>>> diff --git a/platform/linux-generic/include/odp/plat/packet_types.h
>>> b/platform/linux-generic/include/odp/plat/packet_types.h
>>> index 45cb801..afc72f4 100644
>>> --- a/platform/linux-generic/include/odp/plat/packet_types.h
>>> +++ b/platform/linux-generic/include/odp/plat/packet_types.h
>>> @@ -36,6 +36,8 @@ typedef ODP_HANDLE_T(odp_packet_seg_t);
>>>   #define ODP_PACKET_SEG_INVALID _odp_cast_scalar(odp_packet_seg_t,
>>> 0x)
>>> +#define ODP_PACKET_RSS_INVALID _odp_cast_scalar(odp_packet_t, 0)
>
>
> This define is incorrect, I think.
>
>>> +
>>>   /** Get printable format of odp_packet_t */
>>>   static inline uint64_t odp_packet_to_u64(odp_packet_t hdl)
>>>   {
>>> diff --git a/platform/linux-generic/include/odp_packet_internal.h
>>> b/platform/linux-generic/include/odp_packet_internal.h
>>> index 8c41491..6e52713 100644
>>> --- a/platform/linux-generic/include/odp_packet_internal.h
>>> +++ b/platform/linux-generic/include/odp_packet_internal.h
>>> @@ -136,6 +136,7 @@ typedef struct {
>>>   uint32_t tailroom;
>>>   odp_pktio_t input;
>>> +uint32_t rss_hash;  /**< RSS hash value*/
>>
>>
>> is rss_hash always and everywhere 32 bit?
>
>
> I don't think it's guaranteed anywhere. Maybe we should rather use an opaque
> type? But then we would need to provide operator functions for all the
> possible uses, that would be an overkill.
>

So far per my knowledge; Plenty of NIC's example e100/ixgbe/brcm etc
provide 32bit word size. You could add opaque support, but make sure
handle/method are inlined (less expensive); Because its per-pkt
Otherwise overkill. I would prefer keeping it 32bit word size unless
someone speaks / describe their experience on using rss_hash 64bit
word size.

>>
>> Maxim.
>>
>>
>>>   odp_crypto_generic_op_result_t op_result;  /**< Result for
>>> crypto */
>>>   } odp_packet_hdr_t;
>>> diff --git a/platform/linux-generic/odp_packet.c
>>> b/platform/linux-generic/odp_packet.c
>>> index 5581cc4..649071f 100644
>>> --- a/platform/linux-generic/odp_packet.c
>>> +++ b/platform/linux-generic/odp_packet.c
>>> @@ -326,6 +326,20 @@ int odp_packet_l4_offset_set(odp_packet_t pkt,
>>> uint32_t offset)
>>>   return 0;
>>>   }
>>> +uint32_t odp_packet_rss_hash(odp_packet_t pkt)
>>> +{
>>> +odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
>>> +
>>> +return pkt_hdr->rss_hash;
>>> +}
>>> +
>>> +void odp_packet_rss_hash_set(odp_packet_t pkt, uint32_t rss_hash)
>>> +{
>>> +odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
>>> +
>>> +pkt_hdr->rss_hash = rss_hash;
>>> +}
>>> +
>>>   int odp_packet_is_segmented(odp_packet_t pkt)
>>>   {
>>>   return odp_packet_hdr(pkt)->buf_hdr.segcount > 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 v3 2/3] linux-generic: packet: implement RSS hash support

[Santosh Shukla]

On 17 August 2015 at 11:54, Maxim Uvarov  wrote:
> On 08/14/15 21:42, Zoltan Kiss wrote:
>>
>> This platform doesn't compute it, packet_init set it to 0, which happens
>> to be ODP_PACKET_RSS_INVALID.
>>
>> Signed-off-by: Zoltan Kiss 
>> ---
>>   platform/linux-generic/include/odp/plat/packet_types.h |  2 ++
>>   platform/linux-generic/include/odp_packet_internal.h   |  1 +
>>   platform/linux-generic/odp_packet.c| 14
>> ++
>>   3 files changed, 17 insertions(+)
>>
>> diff --git a/platform/linux-generic/include/odp/plat/packet_types.h
>> b/platform/linux-generic/include/odp/plat/packet_types.h
>> index 45cb801..afc72f4 100644
>> --- a/platform/linux-generic/include/odp/plat/packet_types.h
>> +++ b/platform/linux-generic/include/odp/plat/packet_types.h
>> @@ -36,6 +36,8 @@ typedef ODP_HANDLE_T(odp_packet_seg_t);
>> #define ODP_PACKET_SEG_INVALID _odp_cast_scalar(odp_packet_seg_t,
>> 0x)
>>   +#define ODP_PACKET_RSS_INVALID _odp_cast_scalar(odp_packet_t, 0)
>> +
>>   /** Get printable format of odp_packet_t */
>>   static inline uint64_t odp_packet_to_u64(odp_packet_t hdl)
>>   {
>> diff --git a/platform/linux-generic/include/odp_packet_internal.h
>> b/platform/linux-generic/include/odp_packet_internal.h
>> index 8c41491..6e52713 100644
>> --- a/platform/linux-generic/include/odp_packet_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_internal.h
>> @@ -136,6 +136,7 @@ typedef struct {
>> uint32_t tailroom;
>> odp_pktio_t input;
>> +   uint32_t rss_hash;  /**< RSS hash value*/
>
>
> is rss_hash always and everywhere 32 bit?
>

It is nic specific; If you checkout latest nics; rss_hash is 32bit
word long. so Yes.

My Reviewed-by to this patch.

> Maxim.
>
>
>> odp_crypto_generic_op_result_t op_result;  /**< Result for crypto
>> */
>>   } odp_packet_hdr_t;
>> diff --git a/platform/linux-generic/odp_packet.c
>> b/platform/linux-generic/odp_packet.c
>> index 5581cc4..649071f 100644
>> --- a/platform/linux-generic/odp_packet.c
>> +++ b/platform/linux-generic/odp_packet.c
>> @@ -326,6 +326,20 @@ int odp_packet_l4_offset_set(odp_packet_t pkt,
>> uint32_t offset)
>> return 0;
>>   }
>>   +uint32_t odp_packet_rss_hash(odp_packet_t pkt)
>> +{
>> +   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
>> +
>> +   return pkt_hdr->rss_hash;
>> +}
>> +
>> +void odp_packet_rss_hash_set(odp_packet_t pkt, uint32_t rss_hash)
>> +{
>> +   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
>> +
>> +   pkt_hdr->rss_hash = rss_hash;
>> +}
>> +
>>   int odp_packet_is_segmented(odp_packet_t pkt)
>>   {
>> return odp_packet_hdr(pkt)->buf_hdr.segcount > 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 v3 1/3] api: packet: allow access to packet RSS hash values

[Santosh Shukla]

On 15 August 2015 at 00:12, Zoltan Kiss  wrote:
> Applications can read the computed hash (if any) and set it if they
> changed the packet headers or if the platform haven't calculated the hash.
>
> Signed-off-by: Zoltan Kiss 
> ---
> v2:
> - focus on RSS hash only
> - use setter/getter's
>
> v3:
> - do not mention pointers
> - add a note
> - add new patches for implementation and test
>
>  include/odp/api/packet.h | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 3a454b5..1ae24bc 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -48,6 +48,11 @@ extern "C" {
>   * Invalid packet segment
>   */
>
> +/**
> + * @def ODP_PACKET_RSS_INVALID
> + * RSS hash is not set
> + */
> +
>  /*
>   *
>   * Alloc and free
> @@ -605,6 +610,31 @@ uint32_t odp_packet_l4_offset(odp_packet_t pkt);
>  int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t offset);
>
>  /**
> + * RSS hash value
> + *
> + * Returns the RSS hash stored for the packet.
> + *
> + * @param  pkt  Packet handle
> + *
> + * @return  Hash value
> + * @retval ODP_PACKET_RSS_INVALID if RSS hash is not set.
> + */
> +uint32_t odp_packet_rss_hash(odp_packet_t pkt);
> +
> +/**
> + * Set RSS hash value
> + *
> + * Store the RSS hash for the packet.
> + *
> + * @param  pkt  Packet handle
> + * @param  rss_hash Hash value to set
> + *
> + * @note If the application changes the packet header, it might want to
> + * recalculate this value and set it.
> + */
> +void odp_packet_rss_hash_set(odp_packet_t pkt, uint32_t rss_hash);
> +
> +/**
>   * Tests if packet is segmented
>   *
>   * @param pkt  Packet handle
> --

Reviewed-by : Santosh Shukla 

> 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] Test odp_l2fwd in vm guest

[Santosh Shukla]

On 4 May 2015 at 02:15, Hongbo Zhang  wrote:
> On 1 May 2015 at 00:41, Santosh Shukla  wrote:
>> On 30 April 2015 at 09:18, Mike Holmes  wrote:
>>> Is this a good result ?
>>>
>> Nope, and it looks like - they are more functional, perhaps lava
>> integrable material. He's using emulated nic.
>> We did talked about it in one of our odp-virt call.
>
> Right.
>
>>
>>> Are you able to get a comparison to the native platform SDK for the machine
>>> you ran on - if this was x86 can we run native DPDK ?
>>> If this was x86 I assume you used odp-dpdk but maybe you used linux-generic
>>> which will not perform well.
>>>
>>
>> I ran odp-dpdk in guest mode long back. It gives close to line rate
>> however lesser than plain dpdk running in guest. And we know the
>> root-cause. Venky, In very early days did highlighted in his report.
>> But that(s) a different problem and I guess odp-dpdk work likely to
>> address them.
>>
>> However, Hongbo can anyways create a lava setup where odp-dpdk (on x86
>> box, using dpdk favorable nic) doing l2fwd at guest. And that setup
>> shows result in pps, vcpu-utilization and if possible -rtt (i guess:
>> its not there, we'll have to write em).
>>
>
> Yes ,I would like to start a new discuss about setting l2fwd in guest
> in Lava, there are somethings needs to be discussed/confirmed before I
> take further actions.
>
Like ?

Or else setup an HO meet and send an invite for discussion. Thanks.

>> HTH!
>>
>>> On 30 April 2015 at 08:42, Hongbo Zhang  wrote:
>>>>
>>>> Hi,
>>>> I set up a test to run odp in vm guest to get the odp throughput in it,
>>>> idea is:
>>>> in the host run odp_generator to send pkt from host br0 to guest eth0,
>>>> and in the guest, run odp_l2fwd to forward packets from its eth0 to
>>>> eth1, and then in host, run odp_generator to get these packets form
>>>> br1.
>>>>
>>>> Here are steps of my test:
>>>> 0. install tools and compile odp in guest and host.
>>>> 1. host network interface preparation:
>>>> sudo tunctl -u root
>>>> sudo tunctl -u root
>>>> sudo ifconfig tap0 0.0.0.0 up
>>>> sudo ifconfig tap1 0.0.0.0 up
>>>> sudo brctl addbr br0
>>>> sudo brctl addbr br1
>>>> sudo brctl addif br0 tap0 eth2
>>>> sudo brctl addif br1 tap1 eth3
>>>> sudo ifconfig eth2 0.0.0.0
>>>> sudo ifconfig br0 10.0.3.15/24 up
>>>> sudo ifconfig eth3 0.0.0.0
>>>> sudo ifconfig br1 10.0.4.15/24 up
>>>> 2. launch the qemu vm
>>>> sudo qemu-system-i386 -hda debian_wheezy_i386_standard.qcow2 -net
>>>> nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -net
>>>> nic,vlan=1 -net tap,vlan=1,ifname=tap1,script=no,downscript=no -smp 2
>>>> 3. guest network interface configuraton
>>>> ifconfig eth0 10.0.3.16/24 up
>>>> ifconfig eth1 10.0.4.16/24 up
>>>> 4. in the host, in one terminal:
>>>> sudo ./example/generator/odp_generator -m r -I br1
>>>> in another terminal:
>>>> sudo ./example/generator/odp_generator --srcmac 08:00:27:28:3e:ec
>>>> --dstmac 52:54:00:12:34:5-I br0 -m u --srcip 10.0.3.15 --dstip
>>>> 10.0.4.255
>>>> 5. in the guest, start l2fwd:
>>>> ./test/performance/odp_l2fwd - eth0,eth1 -m 0 -t 30
>>>>
>>>> Here are part of results log of l2fwd in guest:
>>>> ..
>>>> 1280 pps, 3158 max pps, 0 total drops
>>>> 1216 pps, 3158 max pps, 0 total drops
>>>> 2016 pps, 3158 max pps, 0 total drops
>>>> 1680 pps, 3158 max pps, 0 total drops
>>>> TEST RESULT: 3158 maximum packets per second.
>>>> ___
>>>> lng-odp mailing list
>>>> lng-odp@lists.linaro.org
>>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>>
>>>
>>>
>>> --
>>> Mike Holmes
>>> Technical Manager - Linaro Networking Group
>>> Linaro.org │ Open source software for ARM SoCs
>>>
>>>
>>>
>>> ___
>>> 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] Test odp_l2fwd in vm guest

[Santosh Shukla]

On 30 April 2015 at 09:18, Mike Holmes  wrote:
> Is this a good result ?
>
Nope, and it looks like - they are more functional, perhaps lava
integrable material. He's using emulated nic.
We did talked about it in one of our odp-virt call.

> Are you able to get a comparison to the native platform SDK for the machine
> you ran on - if this was x86 can we run native DPDK ?
> If this was x86 I assume you used odp-dpdk but maybe you used linux-generic
> which will not perform well.
>

I ran odp-dpdk in guest mode long back. It gives close to line rate
however lesser than plain dpdk running in guest. And we know the
root-cause. Venky, In very early days did highlighted in his report.
But that(s) a different problem and I guess odp-dpdk work likely to
address them.

However, Hongbo can anyways create a lava setup where odp-dpdk (on x86
box, using dpdk favorable nic) doing l2fwd at guest. And that setup
shows result in pps, vcpu-utilization and if possible -rtt (i guess:
its not there, we'll have to write em).

HTH!

> On 30 April 2015 at 08:42, Hongbo Zhang  wrote:
>>
>> Hi,
>> I set up a test to run odp in vm guest to get the odp throughput in it,
>> idea is:
>> in the host run odp_generator to send pkt from host br0 to guest eth0,
>> and in the guest, run odp_l2fwd to forward packets from its eth0 to
>> eth1, and then in host, run odp_generator to get these packets form
>> br1.
>>
>> Here are steps of my test:
>> 0. install tools and compile odp in guest and host.
>> 1. host network interface preparation:
>> sudo tunctl -u root
>> sudo tunctl -u root
>> sudo ifconfig tap0 0.0.0.0 up
>> sudo ifconfig tap1 0.0.0.0 up
>> sudo brctl addbr br0
>> sudo brctl addbr br1
>> sudo brctl addif br0 tap0 eth2
>> sudo brctl addif br1 tap1 eth3
>> sudo ifconfig eth2 0.0.0.0
>> sudo ifconfig br0 10.0.3.15/24 up
>> sudo ifconfig eth3 0.0.0.0
>> sudo ifconfig br1 10.0.4.15/24 up
>> 2. launch the qemu vm
>> sudo qemu-system-i386 -hda debian_wheezy_i386_standard.qcow2 -net
>> nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -net
>> nic,vlan=1 -net tap,vlan=1,ifname=tap1,script=no,downscript=no -smp 2
>> 3. guest network interface configuraton
>> ifconfig eth0 10.0.3.16/24 up
>> ifconfig eth1 10.0.4.16/24 up
>> 4. in the host, in one terminal:
>> sudo ./example/generator/odp_generator -m r -I br1
>> in another terminal:
>> sudo ./example/generator/odp_generator --srcmac 08:00:27:28:3e:ec
>> --dstmac 52:54:00:12:34:5-I br0 -m u --srcip 10.0.3.15 --dstip
>> 10.0.4.255
>> 5. in the guest, start l2fwd:
>> ./test/performance/odp_l2fwd - eth0,eth1 -m 0 -t 30
>>
>> Here are part of results log of l2fwd in guest:
>> ..
>> 1280 pps, 3158 max pps, 0 total drops
>> 1216 pps, 3158 max pps, 0 total drops
>> 2016 pps, 3158 max pps, 0 total drops
>> 1680 pps, 3158 max pps, 0 total drops
>> TEST RESULT: 3158 maximum packets per second.
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org │ Open source software for ARM SoCs
>
>
>
> ___
> 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] Linux odp_l2fwd SIGSEGV during tcp transfer

[Santosh Shukla]

Sorry for no response, I am busy with no_hz_full.

I did saw such crashes but addressed by my own in past. I thought I was
related to my setup and pressing time line to demo work in past so ignored.
Since you too able emulate it therefore file a bug per mike suggested link,
assign to me and I'll respond per my bandwidth.

Thanks.

On 3 December 2014 at 04:19, Mike Holmes  wrote:

> Thanks Shmulik
>
> Hopefully Santosh gets some cycles to look, there is a lot moving right
> now which does not help.
> Worst case can you log it as a bug
> https://bugs.linaro.org/enter_bug.cgi?product=OpenDataPlane
>
> On 2 December 2014 at 05:45, Shmulik Ladkani 
> wrote:
>
>> Hi,
>>
>> I'm having various SIGSEGV crashes in odp_l2fwd during a tcp transfer
>> between 2 interfaces.
>>
>> Running on Linux x86 32bit (3.11); Clean ODP at 1c6711ed1d (Nov 27).
>>
>> # odp_l2fwd -i veth0,veth1 -m 1
>>
>> An example backtrace:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0xb62a5b40 (LWP 22634)]
>> odp_packet_init (pkt=3288626) at odp_packet.c:32
>> 32  memset(start, 0, len);
>> (gdb) bt
>> #0  odp_packet_init (pkt=3288626) at odp_packet.c:32
>> #1  0x0804df0f in odph_packet_alloc (pool_id=2) at
>> ../../helper/include/odph_packet.h:58
>> #2  pkt_mmap_v2_rx (sock=, if_mac=0xb7fd22d4
>> "\002\217^\202u\252", frame_offset=2, pool=2, len=8, pkt_table=0xb62a5180,
>> ring=0xb7fd2240)
>> at odp_packet_socket.c:573
>> #3  recv_pkt_sock_mmap (pkt_sock=0xb7fd2240, pkt_table=0xb62a5180, len=8)
>> at odp_packet_socket.c:893
>> #4  0x0804c8c5 in odp_pktio_recv (id=2, pkt_table=0xb62a5180, len=8) at
>> odp_packet_io.c:276
>> #5  0x0804cd20 in pktin_deq_multi (qentry=0xb7bed940, buf_hdr=0xb62a51f0,
>> num=4) at odp_packet_io.c:471
>> #6  0x0804ea1f in odp_queue_deq_multi (handle=98, buf=0xb62a5b1c, num=4)
>> at odp_queue.c:422
>> #7  0x0804efe7 in schedule (max_deq=4, max_num=1, out_buf=0xb62a529c,
>> out_queue=0x0) at odp_schedule.c:296
>> #8  schedule_loop (out_queue=out_queue@entry=0x0, wait=,
>> out_buf=0xb62a529c, max_num=1, max_deq=4) at odp_schedule.c:349
>> #9  0x0804f1a5 in odp_schedule (out_queue=0x0, wait=0) at
>> odp_schedule.c:382
>> #10 0x08049d7e in pktio_queue_thread (arg=0x16) at odp_l2fwd.c:224
>> #11 0xb7dd2efb in start_thread (arg=0xb62a5b40) at pthread_create.c:309
>> #12 0xb7d0adfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
>>
>> When running in "basic" receive mode (ODP_PKTIO_DISABLE_SOCKET_MMSG=y
>> ODP_PKTIO_DISABLE_SOCKET_MMAP=y) no crashes observed.
>>
>> Is this familiar?
>>
>> Regards,
>> Shmulik
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
> --
> *Mike Holmes*
> Linaro  Sr Technical Manager
> 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

Re: [lng-odp] [PATCH] Removed odp_atomic_int_t

[Santosh Shukla]

>
>
>
> -void test_atomic_inc_dec_32(void);
> -void test_atomic_add_sub_32(void);
>  void test_atomic_inc_dec_u32(void);
>  void test_atomic_add_sub_u32(void);
>  void test_atomic_inc_dec_64(void);
>  void test_atomic_add_sub_64(void);
>
>
>
> so as we should replace above 2 api from _64 to _u64, right?
>
>
>
> I believe this is your code. I didn’t rename functions, just removed those
> using int atomics (signed 32). The _64 functions calls _u64 atomic APIs.
> So, would you like to align function naming  after this patch has been
> merged?
>
>
>

Okay.I'll send out patch depedent on this one.



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

Re: [lng-odp] [PATCH] Removed odp_atomic_int_t

[Santosh Shukla]

On 31 October 2014 19:09, Petri Savolainen 
wrote:

> Integer version is not needed. Unsigned 32 and 64 bit atomics
> are used instead. If signed 32/64 bits can be added later
>

instead - if signed 32/64 bits required then can be added later on need
basis.


on need basis.
>
> Signed-off-by: Petri Savolainen 
> ---
>  platform/linux-generic/include/api/odp_atomic.h| 115
> -
>  platform/linux-generic/include/api/odp_barrier.h   |   4 +-
>  .../linux-generic/include/odp_buffer_internal.h|   2 +-
>  platform/linux-generic/odp_barrier.c   |   6 +-
>  platform/linux-generic/odp_thread.c|   6 +-
>  test/api_test/odp_atomic_test.c|  80 ++
>  test/api_test/odp_atomic_test.h|   9 --
>  7 files changed, 16 insertions(+), 206 deletions(-)
>
> diff --git a/platform/linux-generic/include/api/odp_atomic.h
> b/platform/linux-generic/include/api/odp_atomic.h
> index 213c81f..5c83b39 100644
> --- a/platform/linux-generic/include/api/odp_atomic.h
> +++ b/platform/linux-generic/include/api/odp_atomic.h
> @@ -26,10 +26,6 @@ extern "C" {
>   *  @{
>   */
>
> -/**
> - * Atomic integer
> - */
> -typedef volatile int32_t odp_atomic_int_t;
>
>  /**
>   * Atomic unsigned integer 64 bits
> @@ -43,117 +39,6 @@ typedef volatile uint32_t odp_atomic_u32_t;
>
>
>  /**
> - * Initialize atomic integer
> - *
> - * @param ptrAn integer atomic variable
> - *
> - * @note The operation is not synchronized with other threads
> - */
> -static inline void odp_atomic_init_int(odp_atomic_int_t *ptr)
> -{
> -   *ptr = 0;
> -}
> -
> -/**
> - * Load value of atomic integer
> - *
> - * @param ptrAn atomic variable
> - *
> - * @return atomic integer value
> - *
> - * @note The operation is not synchronized with other threads
> - */
> -static inline int odp_atomic_load_int(odp_atomic_int_t *ptr)
> -{
> -   return *ptr;
> -}
> -
> -/**
> - * Store value to atomic integer
> - *
> - * @param ptrAn atomic variable
> - * @param new_value  Store new_value to a variable
> - *
> - * @note The operation is not synchronized with other threads
> - */
> -static inline void odp_atomic_store_int(odp_atomic_int_t *ptr, int
> new_value)
> -{
> -   *ptr = new_value;
> -}
> -
> -/**
> - * Fetch and add atomic integer
> - *
> - * @param ptrAn atomic variable
> - * @param value  A value to be added to the variable
> - *
> - * @return Value of the variable before the operation
> - */
> -static inline int odp_atomic_fetch_add_int(odp_atomic_int_t *ptr, int
> value)
> -{
> -   return __sync_fetch_and_add(ptr, value);
> -}
> -
> -/**
> - * Fetch and subtract atomic integer
> - *
> - * @param ptrAn atomic integer variable
> - * @param value  A value to be subtracted from the variable
> - *
> - * @return Value of the variable before the operation
> - */
> -static inline int odp_atomic_fetch_sub_int(odp_atomic_int_t *ptr, int
> value)
> -{
> -   return __sync_fetch_and_sub(ptr, value);
> -}
> -
> -/**
> - * Fetch and increment atomic integer by 1
> - *
> - * @param ptrAn atomic variable
> - *
> - * @return Value of the variable before the operation
> - */
> -static inline int odp_atomic_fetch_inc_int(odp_atomic_int_t *ptr)
> -{
> -   return odp_atomic_fetch_add_int(ptr, 1);
> -}
> -
> -/**
> - * Increment atomic integer by 1
> - *
> - * @param ptrAn atomic variable
> - *
> - */
> -static inline void odp_atomic_inc_int(odp_atomic_int_t *ptr)
> -{
> -   odp_atomic_fetch_add_int(ptr, 1);
> -}
> -
> -/**
> - * Fetch and decrement atomic integer by 1
> - *
> - * @param ptrAn atomic int variable
> - *
> - * @return Value of the variable before the operation
> - */
> -static inline int odp_atomic_fetch_dec_int(odp_atomic_int_t *ptr)
> -{
> -   return odp_atomic_fetch_sub_int(ptr, 1);
> -}
> -
> -/**
> - * Decrement atomic integer by 1
> - *
> - * @param ptrAn atomic variable
> - *
> - */
> -static inline void odp_atomic_dec_int(odp_atomic_int_t *ptr)
> -{
> -   odp_atomic_fetch_sub_int(ptr, 1);
> -}
> -
> -/**
>   * Initialize atomic uint32
>   *
>   * @param ptrAn atomic variable
> diff --git a/platform/linux-generic/include/api/odp_barrier.h
> b/platform/linux-generic/include/api/odp_barrier.h
> index 866648f..fb02a9d 100644
> --- a/platform/linux-generic/include/api/odp_barrier.h
> +++ b/platform/linux-generic/include/api/odp_barrier.h
> @@ -31,8 +31,8 @@ extern "C" {
>   * ODP execution barrier
>   */
>  typedef struct odp_barrier_t {
> -   int  count;  /**< @private Thread count */
> -   odp_atomic_int_t bar;/**< @private Barrier counter */
> +   uint32_t count;  /**< @private Thread count */
> +   odp_atomic_u32_t bar;/**< @private Barrier counter */
>  } odp_barrier_t;
>
>
> diff --git a/platform/linux-generic/include/odp_buffer_internal.h
> b/platform/linux-generic/include/odp_buffer_internal.h
> index 2002b51..0027bfc 100644
> --- a/platform/linux-gen

Re: [lng-odp] [PATCH] odp_ring_test.c: free buffer on fail

[Santosh Shukla]

> On 24 October 2014 15:46, Mike Holmes  wrote:
>
>> On data mismatch free the recently mallocked buffer.
>>
>> Signed-off-by: Mike Holmes 
>> ---
>>  test/api_test/odp_ring_test.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
>> index 1da5845..eb1f301 100644
>> --- a/test/api_test/odp_ring_test.c
>> +++ b/test/api_test/odp_ring_test.c
>> @@ -286,6 +286,7 @@ static int consumer_fn(void)
>> if (i == 0) {
>> for (i = 0; i < MAX_BULK; i++) {
>> if (src[i] != (void *)(unsigned long)i) {
>> +   free(src);
>> printf("data mismatch.. lockless
>> ops fail\n");
>> return -1;
>> }
>>
>
+1,

Reviewed-by: Santosh Shukla 

--
>> 2.1.0
>>
>>
>
>
> --
> *Mike Holmes*
> Linaro  Sr Technical Manager
> 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

Re: [lng-odp] [PATCH] Direct access of perf counters from Userspace

[Santosh Shukla]

For that first this patch should be sent as "RFC"  :), Second I agree
with petri about making/ keeping it generic. and Architecture specific
implementation details in separate file, But certainly not a helper/*
one.

@Yogesh, you mentioned that  "SMP support not added", What it mean?

On 26 September 2014 16:30, Mike Holmes  wrote:
> I think this should be a helper unless there a reason it must operate after
> global_init, conceptually to me it functions completely without ODP, but an
> odp control plane might make heavy use of it.
> We should not try to abstract all the counter lables in my opinion, just the
> mechanism to access them, of course we should adopt the regular perf naming
> wherever possible.
>
> A follow on task is to implement this for X86
>
> mike
>
> On 26 September 2014 06:50, Ola Liljedahl  wrote:
>>
>> I agree that this API is needed by ODP. But it is not needed in ODP. This
>> is generic functionality useful for any project. Let's not bind it tightly
>> to ODP.
>> Some event types will be specific to CPU implementations but I think we
>> can handle such dependencies outside of ODP.
>>
>> -- Ola
>>
>> On 26 September 2014 12:28, Savolainen, Petri (NSN - FI/Espoo)
>>  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> An API for CPU perf counters is needed in ODP. It  can be used to
>>> instrument an application with (automatic) performance profiling. Most CPU
>>> architectures have some support for it (== needs abstraction). The patch
>>> should target main API (not helper) and need to be generic (not ARM
>>> specific).
>>>
>>>
>>>
>>>
>>>
>>> Some set of standard events should be defined. Maybe all architectures do
>>> not support all of them.
>>>
>>>
>>>
>>> #define ODP_PERF_CPU_CYCLES 1
>>>
>>> #define ODP_PERF_INSTR 2
>>>
>>> #define ODP_PERF_CACHE_MISSES3
>>>
>>> #define ODP_PERF_BRANCH_MISSES 4
>>>
>>> …
>>>
>>> #define ODP_PERF_L1D_MISSES16
>>>
>>> #define ODP_PERF_L1D_LOAD_MISSES   17
>>>
>>> #define ODP_PERF_L1D_STORE_MISSES 18
>>>
>>> …
>>>
>>>
>>>
>>>
>>>
>>> It should be possible to access multiple counters simultaneously.
>>>
>>>
>>>
>>> /* Setup counters */
>>>
>>> int odp_perf_open_counters(int events[], int num_events)
>>>
>>>
>>>
>>> /* Start counting */
>>>
>>> int odp_perf_start_counters()
>>>
>>>
>>>
>>> /* Read out values */
>>>
>>> int odp_perf_read_counters(uint64_t count[], int num_counters)
>>>
>>>
>>>
>>> /* Zero values */
>>>
>>> int odp_perf_zero_counters()
>>>
>>>
>>>
>>> /* Stop counting */
>>>
>>> int odp_perf_stop_counters()
>>>
>>>
>>>
>>> /* Free counters when not used any more */
>>>
>>> int odp_perf_close_counters()
>>>
>>>
>>>
>>>
>>>
>>> -Petri
>>>
>>>
>>>
>>>
>>>
>>> From: lng-odp-boun...@lists.linaro.org
>>> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
>>> Sent: Friday, September 26, 2014 1:03 PM
>>> To: Yogesh Tillu
>>> Cc: lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] [PATCH] Direct access of perf counters from
>>> Userspace
>>>
>>>
>>>
>>> How does the API to the kernel for enabling user mode access to PMU
>>> registers (especially counters and CCNT) look like?
>>>
>>> Could we use a file in the /sys file system that can be written? There
>>> are other examples of this, e.g. configuring DVFS governors.
>>>
>>> I would love to have this feature as standard in the kernel without
>>> having to build and install a kernel module.
>>>
>>>
>>>
>>> I don't see this as a part of ODP. The user space perf library ought to
>>> be separate. You want to be able to use it for other projects that do not
>>> use ODP. The code is only dependent on ARM architecture and not on any SoC
>>> features (which ODP is there to abstract).
>>>
>>>
>>>
>>> -- Ola
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 26 September 2014 11:46, Yogesh Tillu  wrote:
>>>
>>> Hi,
>>>   This is patch for Initial implementation of API for Direct access of
>>> Perf
>>> counters from userspace, provided as part of header file.
>>> **Assumption:
>>> 1)Kernel will have support for allowing perf counters access from
>>> userspace.
>>> Currently implemented as Module, but in-progress patch for submission to
>>> lng-kernel.
>>> 2)SMP support is not added.
>>> 3)Only Perf cycle counter support is added
>>>
>>> **Support:
>>> ArmV7(Tested on Arndale Board)
>>> ArmV8(Tested on Juno Board)
>>>
>>> **Todo:
>>> 1)Add SMP support
>>> 2)Add support for other perf counters
>>>
>>> Comments are welcome including recommended "location of header file".
>>>
>>> Yogesh Tillu (1):
>>>   [Initial Commit] API for Direct access of perf counters from Userspace
>>>
>>>  helper/include/odph_perf.h | 118
>>> +
>>>  1 file changed, 118 insertions(+)
>>>  create mode 100644 helper/include/odph_perf.h
>>>
>>> --
>>> 1.9.1
>>>
>>>
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>>
>>
>>
>>
>> __

Re: [lng-odp] [ODP/PATCH 2/2] test_api: timer: big endian fix

[Santosh Shukla]

Hi Ankit,

Apply above two patches and let me know your feedback. Thanks.

On 25 September 2014 16:17, Santosh Shukla  wrote:
> Signed-off-by: Santosh Shukla 
> ---
>  test/api_test/odp_timer_ping.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c
> index 29a6392..7406a45 100644
> --- a/test/api_test/odp_timer_ping.c
> +++ b/test/api_test/odp_timer_ping.c
> @@ -305,7 +305,7 @@ static int ping_init(int count, char *name[])
> bzero(&dst_addr, sizeof(dst_addr));
> dst_addr.sin_family = hname->h_addrtype;
> dst_addr.sin_port = 0;
> -   dst_addr.sin_addr.s_addr = *(long *)(void *)hname->h_addr;
> +   inet_pton(AF_INET, name[1], &(dst_addr.sin_addr.s_addr));
> }
> printf("ping to addr %s\n", name[1]);
>
> --
> 1.7.9.5
>

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

[lng-odp] [ODP/PATCH 2/2] test_api: timer: big endian fix

[Santosh Shukla]

Signed-off-by: Santosh Shukla 
---
 test/api_test/odp_timer_ping.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c
index 29a6392..7406a45 100644
--- a/test/api_test/odp_timer_ping.c
+++ b/test/api_test/odp_timer_ping.c
@@ -305,7 +305,7 @@ static int ping_init(int count, char *name[])
bzero(&dst_addr, sizeof(dst_addr));
dst_addr.sin_family = hname->h_addrtype;
dst_addr.sin_port = 0;
-   dst_addr.sin_addr.s_addr = *(long *)(void *)hname->h_addr;
+   inet_pton(AF_INET, name[1], &(dst_addr.sin_addr.s_addr));
}
printf("ping to addr %s\n", name[1]);
 
-- 
1.7.9.5


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

[lng-odp] [ODP/PATCH 1/2] test_api: timer: odp_timer_create error check

[Santosh Shukla]

Also set appropriate timer resolution. w/o this error check odp ping
application will segfault.

Signed-off-by: Santosh Shukla 
---
 test/api_test/odp_timer_ping.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c
index 5ae379f..29a6392 100644
--- a/test/api_test/odp_timer_ping.c
+++ b/test/api_test/odp_timer_ping.c
@@ -43,6 +43,11 @@
 #define PING_CNT   10
 #define PING_THRD  2   /* Send and Rx Ping thread */
 
+/* Nanoseconds */
+#define RESUS  1
+#define MINUS  1
+#define MAXUS  1000
+
 static odp_timer_t test_timer_ping;
 static odp_timer_tmo_t test_ping_tmo;
 
@@ -353,7 +358,15 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED)
}
 
test_timer_ping = odp_timer_create("ping_timer", pool,
-  100, 100, 1UL);
+  RESUS*ODP_TIME_USEC,
+  MINUS*ODP_TIME_USEC,
+  MAXUS*ODP_TIME_USEC);
+
+   if (test_timer_ping == ODP_TIMER_INVALID) {
+   ODP_ERR("Timer create failed.\n");
+   return -1;
+   }
+
odp_shm_print_all();
 
pingarg.thrdarg.testcase = ODP_TIMER_PING_TEST;
-- 
1.7.9.5


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

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 5 September 2014 03:16, Mike Holmes  wrote:
> Yes, but that may be my ignorance :)  I don't know why the old way is needed
> now.

Thats may be because I was confused and getting impression that
expectation to do two level of argument processing although sounds
stupid so thats why wanted to be loud and clear.

I could send param specific dpdk-l2fwd patch to list now. Thanks for
clarification.

>
>
> On 4 September 2014 17:44, Santosh Shukla  wrote:
>>
>> On 5 September 2014 03:08, Mike Holmes  wrote:
>> >
>> >
>> >
>> > On 4 September 2014 17:30, Santosh Shukla 
>> > wrote:
>> >>
>> >> On 5 September 2014 00:13, Mike Holmes  wrote:
>> >> > I am confused about the init sequence, I imagine this
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 4 September 2014 04:40, Santosh Shukla 
>> >> > wrote:
>> >> >>
>> >> >> On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo)
>> >> >>  wrote:
>> >> >> >> Conti..
>> >> >> >>
>> >> >> >> Root cause of my concern is not entirely specific to this patch.
>> >> >> >> Its
>> >> >> >> more related to odp api initialization calling sequence in
>> >> >> >> application. From early days, we used to follow below step in
>> >> >> >> application -
>> >> >> >>
>> >> >> >> odp_global_init() -> which does almost everything for platform
>> >> >> >> initialization.
>> >> >> >> odp_shm_reserve() -> used for argument processing then
>> >> >> >> odp_create_thread etc...
>> >> >> >>
>> >> >> >> Now we found a need to introduce platform specific init hints,
>> >> >> >> coming
>> >> >> >> from application. Therefore order of odp_xxx_init api calling
>> >> >> >> sequence
>> >> >> >> should change too.
>> >> >> >>
>> >> >> >>
>> >> >> >> Something like.
>> >> >> >>
>> >> >> >> Application "X"
>> >> >> >>
>> >> >> >> main ()
>> >> >> >> {
>> >> >> >>
>> >> >> >> - First do argument processing. For that, call odp_shm_init() in
>> >> >> >> application and remove it from odp_global_init OR application has
>> >> >> >> to
>> >> >> >> allocate memory(bad idea ... I guess).
>> >> >> >
>> >> >> > argX and argY can be allocated from stack or heap (malloc). Shared
>> >> >> > memory is not needed for those to be able to call
>> >> >> > odp_global_init().
>> >> >> > ODP
>> >> >> > will take copy of the argument, argX/Y can be destroyed after the
>> >> >> > call.
>> >> >>
>> >> >> Not to *call odp_global_init* , It is to pass command line processed
>> >> >> input to odp_globa_init().. Are you suggesting calling of
>> >> >> parse_args()
>> >> >> before and after odp_global_init()?
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > After ODP init, you can allocate shm and copy args there if you
>> >> >> > need
>> >> >> > to
>> >> >> > share those within your app.
>> >> >>
>> >> >> Same argument processed twice ? isn't it.
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > -Petri
>> >> >> >
>> >> >> >>
>> >> >> >> - Then call odp_global/platform_init(argX, argY); where arg -X :
>> >> >> >> global param, Y :  platform centric stuff.
>> >> >> >>
>> >> >> >> ... Rest stuff as it is.
>> >> >> >> }
>> >> >> >>
>> >> >> >>
>> >> >> >> Any idea? thoughts? Does above make sense. Thanks.
>> >> >> >>
>> >> >> >>
>> >> >
>&g

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 5 September 2014 03:08, Mike Holmes  wrote:
>
>
>
> On 4 September 2014 17:30, Santosh Shukla  wrote:
>>
>> On 5 September 2014 00:13, Mike Holmes  wrote:
>> > I am confused about the init sequence, I imagine this
>> >
>> >
>> >
>> >
>> > On 4 September 2014 04:40, Santosh Shukla 
>> > wrote:
>> >>
>> >> On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo)
>> >>  wrote:
>> >> >> Conti..
>> >> >>
>> >> >> Root cause of my concern is not entirely specific to this patch. Its
>> >> >> more related to odp api initialization calling sequence in
>> >> >> application. From early days, we used to follow below step in
>> >> >> application -
>> >> >>
>> >> >> odp_global_init() -> which does almost everything for platform
>> >> >> initialization.
>> >> >> odp_shm_reserve() -> used for argument processing then
>> >> >> odp_create_thread etc...
>> >> >>
>> >> >> Now we found a need to introduce platform specific init hints,
>> >> >> coming
>> >> >> from application. Therefore order of odp_xxx_init api calling
>> >> >> sequence
>> >> >> should change too.
>> >> >>
>> >> >>
>> >> >> Something like.
>> >> >>
>> >> >> Application "X"
>> >> >>
>> >> >> main ()
>> >> >> {
>> >> >>
>> >> >> - First do argument processing. For that, call odp_shm_init() in
>> >> >> application and remove it from odp_global_init OR application has to
>> >> >> allocate memory(bad idea ... I guess).
>> >> >
>> >> > argX and argY can be allocated from stack or heap (malloc). Shared
>> >> > memory is not needed for those to be able to call odp_global_init().
>> >> > ODP
>> >> > will take copy of the argument, argX/Y can be destroyed after the
>> >> > call.
>> >>
>> >> Not to *call odp_global_init* , It is to pass command line processed
>> >> input to odp_globa_init().. Are you suggesting calling of parse_args()
>> >> before and after odp_global_init()?
>> >>
>> >>
>> >> >
>> >> > After ODP init, you can allocate shm and copy args there if you need
>> >> > to
>> >> > share those within your app.
>> >>
>> >> Same argument processed twice ? isn't it.
>> >>
>> >>
>> >>
>> >> >
>> >> > -Petri
>> >> >
>> >> >>
>> >> >> - Then call odp_global/platform_init(argX, argY); where arg -X :
>> >> >> global param, Y :  platform centric stuff.
>> >> >>
>> >> >> ... Rest stuff as it is.
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Any idea? thoughts? Does above make sense. Thanks.
>> >> >>
>> >> >>
>> >
>> >
>> > My view was that it went like this :
>> >
>> >
>> > main starts(args passed in)
>> > int foo;
>> > odp_init_t odp_data
>> >  odp_platform_init_t  platform_data
>> >
>> > /*Process the arguments passed in as normal.*/
>> > loop {
>> >   Set variables that main will use itself i.e. if --use-foo is passed
>> > set
>> > foo=true locally.
>> >   Prepare odp_data to pass things into the implementation that ODP
>> > specifies,  <- the internals of odp_data may be an argv string or a tidy
>> > struct we define populated by an ODP helper
>> >   Prepare platform_data packaging any params required into the platform
>> > specific struct.  <- Have no idea what these are, platform needs to
>> > figure
>> > this out
>> > }
>> >
>>
>> Not sure I understood your proposal/pseudo flow completely.
>>
>> = Are you suggesting processing argument twice one for platform_init
>> second for odp thread?
>>
> no, all arguments into main are processed once up front, they are either
> 1. recorded with local variables as appropriate
> 2. stuffed into odp_init - maybe with the helper
> 3. stuffed into odp_platform_init however that platform specifies it should
> be done.
>
>

Which mean ignore old way of argument processing using odp shmem? right.

>> > call global init(odp_data, platform_data) with the above
>> >
>> > 
>> >
>> > /* Act on any remaining parameters such as foo. */
>> > if (foo)
>> >
>> >
>> > --
>> > Mike Holmes
>> > Linaro Technical Manager / Lead
>> > LNG - ODP
>
>
>
>
> --
> Mike Holmes
> Linaro Technical Manager / Lead
> LNG - ODP

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

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 5 September 2014 00:13, Mike Holmes  wrote:
> I am confused about the init sequence, I imagine this
>
>
>
>
> On 4 September 2014 04:40, Santosh Shukla  wrote:
>>
>> On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo)
>>  wrote:
>> >> Conti..
>> >>
>> >> Root cause of my concern is not entirely specific to this patch. Its
>> >> more related to odp api initialization calling sequence in
>> >> application. From early days, we used to follow below step in
>> >> application -
>> >>
>> >> odp_global_init() -> which does almost everything for platform
>> >> initialization.
>> >> odp_shm_reserve() -> used for argument processing then
>> >> odp_create_thread etc...
>> >>
>> >> Now we found a need to introduce platform specific init hints, coming
>> >> from application. Therefore order of odp_xxx_init api calling sequence
>> >> should change too.
>> >>
>> >>
>> >> Something like.
>> >>
>> >> Application "X"
>> >>
>> >> main ()
>> >> {
>> >>
>> >> - First do argument processing. For that, call odp_shm_init() in
>> >> application and remove it from odp_global_init OR application has to
>> >> allocate memory(bad idea ... I guess).
>> >
>> > argX and argY can be allocated from stack or heap (malloc). Shared
>> > memory is not needed for those to be able to call odp_global_init(). ODP
>> > will take copy of the argument, argX/Y can be destroyed after the call.
>>
>> Not to *call odp_global_init* , It is to pass command line processed
>> input to odp_globa_init().. Are you suggesting calling of parse_args()
>> before and after odp_global_init()?
>>
>>
>> >
>> > After ODP init, you can allocate shm and copy args there if you need to
>> > share those within your app.
>>
>> Same argument processed twice ? isn't it.
>>
>>
>>
>> >
>> > -Petri
>> >
>> >>
>> >> - Then call odp_global/platform_init(argX, argY); where arg -X :
>> >> global param, Y :  platform centric stuff.
>> >>
>> >> ... Rest stuff as it is.
>> >> }
>> >>
>> >>
>> >> Any idea? thoughts? Does above make sense. Thanks.
>> >>
>> >>
>
>
> My view was that it went like this :
>
>
> main starts(args passed in)
> int foo;
> odp_init_t odp_data
>  odp_platform_init_t  platform_data
>
> /*Process the arguments passed in as normal.*/
> loop {
>   Set variables that main will use itself i.e. if --use-foo is passed  set
> foo=true locally.
>   Prepare odp_data to pass things into the implementation that ODP
> specifies,  <- the internals of odp_data may be an argv string or a tidy
> struct we define populated by an ODP helper
>   Prepare platform_data packaging any params required into the platform
> specific struct.  <- Have no idea what these are, platform needs to figure
> this out
> }
>

Not sure I understood your proposal/pseudo flow completely.

= Are you suggesting processing argument twice one for platform_init
second for odp thread?

> call global init(odp_data, platform_data) with the above
>
> 
>
> /* Act on any remaining parameters such as foo. */
> if (foo)
>
>
> --
> Mike Holmes
> Linaro Technical Manager / Lead
> LNG - ODP

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

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo)
 wrote:
>> Conti..
>>
>> Root cause of my concern is not entirely specific to this patch. Its
>> more related to odp api initialization calling sequence in
>> application. From early days, we used to follow below step in
>> application -
>>
>> odp_global_init() -> which does almost everything for platform
>> initialization.
>> odp_shm_reserve() -> used for argument processing then
>> odp_create_thread etc...
>>
>> Now we found a need to introduce platform specific init hints, coming
>> from application. Therefore order of odp_xxx_init api calling sequence
>> should change too.
>>
>>
>> Something like.
>>
>> Application "X"
>>
>> main ()
>> {
>>
>> - First do argument processing. For that, call odp_shm_init() in
>> application and remove it from odp_global_init OR application has to
>> allocate memory(bad idea ... I guess).
>
> argX and argY can be allocated from stack or heap (malloc). Shared memory is 
> not needed for those to be able to call odp_global_init(). ODP will take copy 
> of the argument, argX/Y can be destroyed after the call.

Not to *call odp_global_init* , It is to pass command line processed
input to odp_globa_init().. Are you suggesting calling of parse_args()
before and after odp_global_init()?


>
> After ODP init, you can allocate shm and copy args there if you need to share 
> those within your app.

Same argument processed twice ? isn't it.



>
> -Petri
>
>>
>> - Then call odp_global/platform_init(argX, argY); where arg -X :
>> global param, Y :  platform centric stuff.
>>
>> ... Rest stuff as it is.
>> }
>>
>>
>> Any idea? thoughts? Does above make sense. Thanks.
>>
>>

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

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 4 September 2014 10:18, Santosh Shukla  wrote:
> On 3 September 2014 15:48, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
>>
>>
>>> -Original Message-
>>> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
>>> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
>>> Sent: Tuesday, September 02, 2014 9:06 PM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] [PATCH v5] Add-global_init-paramiters
>>>
>>> Signed-off-by: Mike Holmes 
>>> ---
>>>
>>> v2:
>>> Factor out odp_platform_init so that odp_global_init is only defined
>>> for linux_generic and resued.
>>>
>>> v3:
>>> Use -M to simplify the diff
>>> Fix missing doxygen comments
>>>
>>> v4:
>>> Improve the documentation.
>>>
>>> v5:
>>> rename typedef struct names
>>>
>>> This touches all platforms to get crypto working with generic init, DPDK
>>> should
>>> be using generic crypto but obviously KS2 will replace this.
>>> A platform may replace global init entirely but this patch starts out
>>> assuming
>>> that the sub module inits can be called from a central global_init as a
>>> starting
>>> point.
>>>
>>>  example/generator/odp_generator.c  |  2 +-
>>>  example/l2fwd/odp_l2fwd.c  |  2 +-
>>>  example/odp_example/odp_example.c  |  2 +-
>>>  example/packet/odp_pktio.c |  2 +-
>>>  example/timer/odp_timer_test.c |  2 +-
>>>  platform/linux-dpdk/Makefile.am|  4 +-
>>>  platform/linux-dpdk/{odp_init.c => odp_platform.c} | 66 +
>>> --
>>>  platform/linux-generic/Makefile.am |  1 +
>>>  platform/linux-generic/include/api/odp.h   |  1 +
>>>  platform/linux-generic/include/api/odp_init.h  | 34 +++---
>>>  platform/linux-generic/include/odp_internal.h  |  3 +
>>>  platform/linux-generic/odp_init.c  |  9 ++-
>>>  platform/linux-generic/odp_platform.c  | 14 
>>>  platform/linux-keystone2/Makefile.am   |  4 +-
>>>  .../linux-keystone2/{odp_init.c => odp_platform.c} | 74 ++---
>>> -
>>>  test/api_test/odp_common.c |  2 +-
>>>  16 files changed, 73 insertions(+), 149 deletions(-)
>>>  rename platform/linux-dpdk/{odp_init.c => odp_platform.c} (50%)
>>>  create mode 100644 platform/linux-generic/odp_platform.c
>>>  rename platform/linux-keystone2/{odp_init.c => odp_platform.c} (72%)
>>>
>>> diff --git a/example/generator/odp_generator.c
>>> b/example/generator/odp_generator.c
>>> index 9fa9b37..ba7aa68 100644
>>> --- a/example/generator/odp_generator.c
>>> +++ b/example/generator/odp_generator.c
>>> @@ -525,7 +525,7 @@ int main(int argc, char *argv[])
>>>   int core_count;
>>>
>>>   /* Init ODP before calling anything else */
>>> - if (odp_init_global()) {
>>> + if (odp_init_global(NULL, NULL)) {
>>>   ODP_ERR("Error: ODP global init failed.\n");
>>>   exit(EXIT_FAILURE);
>>>   }
>>> diff --git a/example/l2fwd/odp_l2fwd.c b/example/l2fwd/odp_l2fwd.c
>>> index d74449a..f8d6729 100644
>>> --- a/example/l2fwd/odp_l2fwd.c
>>> +++ b/example/l2fwd/odp_l2fwd.c
>>> @@ -323,7 +323,7 @@ int main(int argc, char *argv[])
>>>   odp_pktio_t pktio;
>>>
>>>   /* Init ODP before calling anything else */
>>> - if (odp_init_global()) {
>>> + if (odp_init_global(NULL, NULL)) {
>>>   ODP_ERR("Error: ODP global init failed.\n");
>>>   exit(EXIT_FAILURE);
>>>   }
>>> diff --git a/example/odp_example/odp_example.c
>>> b/example/odp_example/odp_example.c
>>> index f0bdf29..3d38ac7 100644
>>> --- a/example/odp_example/odp_example.c
>>> +++ b/example/odp_example/odp_example.c
>>> @@ -951,7 +951,7 @@ int main(int argc, char *argv[])
>>>
>>>   memset(thread_tbl, 0, sizeof(thread_tbl));
>>>
>>> - if (odp_init_global()) {
>>> + if (odp_init_global(NULL, NULL)) {
>>>   printf("ODP global init failed.\n");
>>>   return -1;
>>>   }
>>> diff --git a/exampl

Re: [lng-odp] [PATCH v5] Add-global_init-paramiters

[Santosh Shukla]

On 3 September 2014 15:48, Savolainen, Petri (NSN - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
>> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
>> Sent: Tuesday, September 02, 2014 9:06 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH v5] Add-global_init-paramiters
>>
>> Signed-off-by: Mike Holmes 
>> ---
>>
>> v2:
>> Factor out odp_platform_init so that odp_global_init is only defined
>> for linux_generic and resued.
>>
>> v3:
>> Use -M to simplify the diff
>> Fix missing doxygen comments
>>
>> v4:
>> Improve the documentation.
>>
>> v5:
>> rename typedef struct names
>>
>> This touches all platforms to get crypto working with generic init, DPDK
>> should
>> be using generic crypto but obviously KS2 will replace this.
>> A platform may replace global init entirely but this patch starts out
>> assuming
>> that the sub module inits can be called from a central global_init as a
>> starting
>> point.
>>
>>  example/generator/odp_generator.c  |  2 +-
>>  example/l2fwd/odp_l2fwd.c  |  2 +-
>>  example/odp_example/odp_example.c  |  2 +-
>>  example/packet/odp_pktio.c |  2 +-
>>  example/timer/odp_timer_test.c |  2 +-
>>  platform/linux-dpdk/Makefile.am|  4 +-
>>  platform/linux-dpdk/{odp_init.c => odp_platform.c} | 66 +
>> --
>>  platform/linux-generic/Makefile.am |  1 +
>>  platform/linux-generic/include/api/odp.h   |  1 +
>>  platform/linux-generic/include/api/odp_init.h  | 34 +++---
>>  platform/linux-generic/include/odp_internal.h  |  3 +
>>  platform/linux-generic/odp_init.c  |  9 ++-
>>  platform/linux-generic/odp_platform.c  | 14 
>>  platform/linux-keystone2/Makefile.am   |  4 +-
>>  .../linux-keystone2/{odp_init.c => odp_platform.c} | 74 ++---
>> -
>>  test/api_test/odp_common.c |  2 +-
>>  16 files changed, 73 insertions(+), 149 deletions(-)
>>  rename platform/linux-dpdk/{odp_init.c => odp_platform.c} (50%)
>>  create mode 100644 platform/linux-generic/odp_platform.c
>>  rename platform/linux-keystone2/{odp_init.c => odp_platform.c} (72%)
>>
>> diff --git a/example/generator/odp_generator.c
>> b/example/generator/odp_generator.c
>> index 9fa9b37..ba7aa68 100644
>> --- a/example/generator/odp_generator.c
>> +++ b/example/generator/odp_generator.c
>> @@ -525,7 +525,7 @@ int main(int argc, char *argv[])
>>   int core_count;
>>
>>   /* Init ODP before calling anything else */
>> - if (odp_init_global()) {
>> + if (odp_init_global(NULL, NULL)) {
>>   ODP_ERR("Error: ODP global init failed.\n");
>>   exit(EXIT_FAILURE);
>>   }
>> diff --git a/example/l2fwd/odp_l2fwd.c b/example/l2fwd/odp_l2fwd.c
>> index d74449a..f8d6729 100644
>> --- a/example/l2fwd/odp_l2fwd.c
>> +++ b/example/l2fwd/odp_l2fwd.c
>> @@ -323,7 +323,7 @@ int main(int argc, char *argv[])
>>   odp_pktio_t pktio;
>>
>>   /* Init ODP before calling anything else */
>> - if (odp_init_global()) {
>> + if (odp_init_global(NULL, NULL)) {
>>   ODP_ERR("Error: ODP global init failed.\n");
>>   exit(EXIT_FAILURE);
>>   }
>> diff --git a/example/odp_example/odp_example.c
>> b/example/odp_example/odp_example.c
>> index f0bdf29..3d38ac7 100644
>> --- a/example/odp_example/odp_example.c
>> +++ b/example/odp_example/odp_example.c
>> @@ -951,7 +951,7 @@ int main(int argc, char *argv[])
>>
>>   memset(thread_tbl, 0, sizeof(thread_tbl));
>>
>> - if (odp_init_global()) {
>> + if (odp_init_global(NULL, NULL)) {
>>   printf("ODP global init failed.\n");
>>   return -1;
>>   }
>> diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
>> index f247bd0..f3543a0 100644
>> --- a/example/packet/odp_pktio.c
>> +++ b/example/packet/odp_pktio.c
>> @@ -311,7 +311,7 @@ int main(int argc, char *argv[])
>>   int core_count;
>>
>>   /* Init ODP before calling anything else */
>> - if (odp_init_global()) {
>> + if (odp_init_global(NULL, NULL)) {
>>   ODP_ERR("Error: ODP global init failed.\n");
>>   exit(EXIT_FAILURE);
>>   }
>> diff --git a/example/timer/odp_timer_test.c
>> b/example/timer/odp_timer_test.c
>> index bf1d7df..abf90aa 100644
>> --- a/example/timer/odp_timer_test.c
>> +++ b/example/timer/odp_timer_test.c
>> @@ -260,7 +260,7 @@ int main(int argc, char *argv[])
>>
>>   memset(thread_tbl, 0, sizeof(thread_tbl));
>>
>> - if (odp_init_global()) {
>> + if (odp_init_global(NULL, NULL)) {
>>   printf("ODP global init failed.\n");
>>   return -1;
>>   }
>> diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-
>> dpdk/Makefile.am
>> index ff49b7d..48fc9d7 100644
>> --- a/platform/linux-dpdk/Makefile.am

Re: [lng-odp] ODP-DPDK multi queue support

[Santosh Shukla]

"Patch to test multi-queue support on ODP-DPDK without " with multi-queue.

Tested-by : Santosh Shukla 

On 3 September 2014 16:10, Santosh Shukla  wrote:
> Confirmed. It is working.
>
> On 1 September 2014 14:09, Venkatesh Vivekanandan
>  wrote:
>>
>>
>>
>> On 28 August 2014 12:04, Santosh Shukla  wrote:
>>>
>>> No hw availability for this week, Next week I will have x86 boxes with
>>> me so expect to see multi-queue update from me. Thanks.
>>>
>>
>> It is better if you can close this off when your setup is back. It takes
>> hardly 10-15 min once you have the setup.
>>
>>>
>>> On 28 August 2014 12:01, Venkatesh Vivekanandan
>>>  wrote:
>>> > Hi Santosh/Mike,
>>> >
>>> > I would like to get this to closure. Can you please check the
>>> > multi-queue
>>> > support for odp-dpdk?. It is just that you have to generate packets with
>>> > different dstip's from odp_generator. Please refer "Patch to test
>>> > multi-queue support on ODP-DPDK without Ixia" email for the test setup.
>>> > Please let me know if you need any help.
>>> >
>>> > Thanks,
>>> > Venkatesh.
>>> >
>>> > ___
>>> > 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

Re: [lng-odp] ODP-DPDK multi queue support

[Santosh Shukla]

Confirmed. It is working.

On 1 September 2014 14:09, Venkatesh Vivekanandan
 wrote:
>
>
>
> On 28 August 2014 12:04, Santosh Shukla  wrote:
>>
>> No hw availability for this week, Next week I will have x86 boxes with
>> me so expect to see multi-queue update from me. Thanks.
>>
>
> It is better if you can close this off when your setup is back. It takes
> hardly 10-15 min once you have the setup.
>
>>
>> On 28 August 2014 12:01, Venkatesh Vivekanandan
>>  wrote:
>> > Hi Santosh/Mike,
>> >
>> > I would like to get this to closure. Can you please check the
>> > multi-queue
>> > support for odp-dpdk?. It is just that you have to generate packets with
>> > different dstip's from odp_generator. Please refer "Patch to test
>> > multi-queue support on ODP-DPDK without Ixia" email for the test setup.
>> > Please let me know if you need any help.
>> >
>> > Thanks,
>> > Venkatesh.
>> >
>> > ___
>> > 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

Re: [lng-odp] [PATCH v4] Add-global_init-paramiters

[Santosh Shukla]

Mike,
I am finding it difficult to use this patch for my use-case where
l2fwd passing  "coremask" param to linux-dpdk layer.  My
implementation takes coremask value from "l2fwd command line argument
-c" and processing of command line argument happens after
odp_global_init().

odp_global_init is first api to call in any application and it does
essential service init like shared mem, its lock etc.. thereafter
argument processing happens so which mean passing
odp_xxx_platform_init_t from odp_global_init wont really help..
What do you thin?

Thanks.

On 2 September 2014 02:25, Bill Fischofer  wrote:
> Let's discuss these scenarios during tomorrow's ODP calls.  Could the
> various camps put together a brief summary of how they see this organized?
> That would be helpful in framing the discussion.
>
> Thanks.
>
> Bill
>
>
> On Mon, Sep 1, 2014 at 5:01 AM, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
>>
>>
>>
>> > -Original Message-
>> > From: ext Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
>> > Sent: Monday, September 01, 2014 11:27 AM
>> > To: Savolainen, Petri (NSN - FI/Espoo)
>> > Cc: ext Mike Holmes; lng-odp@lists.linaro.org
>> > Subject: Re: [lng-odp] [PATCH v4] Add-global_init-paramiters
>> >
>> >
>> > On Sep 1, 2014, at 3:07 AM, Savolainen, Petri (NSN - FI/Espoo)
>> >  wrote:
>> >
>> > >> diff --git a/platform/linux-generic/odp_init.c b/platform/linux-
>> > >> generic/odp_init.c
>> > >> index 5b7e192..f595def 100644
>> > >> --- a/platform/linux-generic/odp_init.c
>> > >> +++ b/platform/linux-generic/odp_init.c
>> > >> @@ -8,13 +8,18 @@
>> > >>   #include 
>> > >>   #include 
>> > >>
>> > >> -
>> > >> -int odp_init_global(void)
>> > >> +int odp_init_global(odp_global_init_t *params  ODP_UNUSED,
>> > >> + odp_global_platform_init_t *platform_params
>> > ODP_UNUSED)
>> > >>   {
>> > >>odp_thread_init_global();
>> > >>
>> > >>odp_system_info_init();
>> > >>
>> > >> + if (odp_init_platform(platform_params)) {
>> > >> platform_params is used here, so remove ODP_UNUSED from argument
>> > >> list.
>> > >
>> > >>> On the other hand, it would be better to remove odp_init_platform()
>> > >>> altogether since does not do anything. It's better to add it when
>> > actually used.
>> > >>> The order of init calls is very important, e.g. now you could not
>> > allocate shared
>> > >>> memory in odp_init_platform() because it's executed before shm
>> > >>> init...
>> > >>  odp_init_platform() does do something for DPDK / KS2 and we need a
>> > place holder because
>> > >> we want this to be shared between implementations don't we ?
>> > >> This is the stuff that must happen before any ODP init starts to
>> > satisfy the platform SDK
>> > >
>> > > Internals of odp_init_global() is totally platform independent - it
>> > cannot be shared in general. It's HW/OS/ODP implementation dependent
>> > what
>> > needs to be initialized in global init, and in which order (e.g. HW
>> > spinlocks before shm, shm before barriers, etc.).
>> >
>> > All of the platform dependent inits should be in the odp_init_platform()
>> > and the calls from odp_init() should be generic for all Linux platforms.
>> > The odp_init_platform() should be close to the bottom of the odp_init()
>> > routine as no routine called before the platform init should require any
>> > thing from the platform.
>> >
>> > If someone can point out why odp_init() is not generic with specific
>> > examples that would help as I do not see any of the above examples as
>> > being platform specific. Why would sum, spin locks and barriers (which
>> > are
>> > linux features) need to be in the platform.
>>
>> The init order depends on implementation internal dependencies. E.g. if a
>> queue implementation uses pools, pools have to be initialized before queues
>> (and pools cannot use queues for their implementation) -  BUT if a pool
>> implementation uses queues, queues have to be init before pools, etc.
>> There's no point to standardize implementation internals, here or elsewhere.
>>
>> Although an implementation may run on Linux, e.g a spinlock may be
>> implement with SW, HW queues or more specific HW...
>>
>>
>> -Petri
>>
>>
>> ___
>> 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

Re: [lng-odp] ODP-DPDK multi queue support

[Santosh Shukla]

No hw availability for this week, Next week I will have x86 boxes with
me so expect to see multi-queue update from me. Thanks.

On 28 August 2014 12:01, Venkatesh Vivekanandan
 wrote:
> Hi Santosh/Mike,
>
> I would like to get this to closure. Can you please check the multi-queue
> support for odp-dpdk?. It is just that you have to generate packets with
> different dstip's from odp_generator. Please refer "Patch to test
> multi-queue support on ODP-DPDK without Ixia" email for the test setup.
> Please let me know if you need any help.
>
> Thanks,
> Venkatesh.
>
> ___
> 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

Re: [lng-odp] [PATCH] test/api_test/odp_ring_test.c: clear clang warning

[Santosh Shukla]

On 26 August 2014 18:02, Santosh Shukla  wrote:
> On 26 August 2014 17:33, Anders Roxell  wrote:
>> On 2014-08-26 12:37, Santosh Shukla wrote:
>>> On 26 August 2014 01:02, Anders Roxell  wrote:
>>> > Remove dead initialisation.
>>> >
>>> > Signed-off-by: Anders Roxell 
>>> > ---
>>> >  test/api_test/odp_ring_test.c | 6 --
>>> >  1 file changed, 6 deletions(-)
>>> >
>>> > diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
>>> > index 6c2642e..93bd869 100644
>>> > --- a/test/api_test/odp_ring_test.c
>>> > +++ b/test/api_test/odp_ring_test.c
>>> > @@ -103,7 +103,6 @@ static int test_ring_basic(odp_ring_t *r)
>>> >
>>> > printf("enqueue MAX_BULK objs\n");
>>> > ret = odp_ring_sp_enqueue_burst(r, cur_src, MAX_BULK);
>>> > -   cur_src += MAX_BULK;
>>> > if ((ret & ODP_RING_SZ_MASK) != MAX_BULK) {
>>> > ODP_ERR("sp_enq for %d obj failed\n", MAX_BULK);
>>> > goto fail;
>>> > @@ -160,7 +159,6 @@ static int test_ring_basic(odp_ring_t *r)
>>> > }
>>> > printf("enqueue MAX_BULK objs\n");
>>> > ret = odp_ring_mp_enqueue_bulk(r, cur_src, MAX_BULK);
>>> > -   cur_src += MAX_BULK;
>>> > if (ret != 0) {
>>> > ODP_ERR("mp_enq for %d obj failed\n", MAX_BULK);
>>> > goto fail;
>>> > @@ -192,9 +190,6 @@ static int test_ring_basic(odp_ring_t *r)
>>> > goto fail;
>>> > }
>>> >
>>> > -   cur_src = src;
>>> > -   cur_dst = dst;
>>> > -
>>>
>>> Rest of looks fine to me except above.. why you want to remove them?
>>
>> because they are not needed... if you look in the file before and after
>> you will see them again 4 lines down...
>
> Yes.
>>
>>
>>>
>>> If above change reverted then Reviewed-by : Santosh Shukla
>>> 
>>>
>>>
>>> > printf("test watermark and default bulk enqueue / dequeue\n");
>>> > odp_ring_set_water_mark(r, 20);
>>> > num_elems = 16;
>>
>> if the diff showed more you would see them here as well... and this one
>> I didn't remove...
>
> I didn't understood above.

Per small HO session :) , Change look good to me. Thanks.

>>
>>> > @@ -209,7 +204,6 @@ static int test_ring_basic(odp_ring_t *r)
>>> > goto fail;
>>> > }
>>> > ret = odp_ring_mp_enqueue_bulk(r, cur_src, num_elems);
>>> > -   cur_src += num_elems;
>>> > if (ret != -EDQUOT) {
>>> > ODP_ERR("Watermark not exceeded\n");
>>> > goto fail;
>>> > --
>>> > 1.9.1
>>> >
>>> >
>>> > ___
>>> > 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

Re: [lng-odp] [PATCH] test/api_test/odp_ring_test.c: clear clang warning

[Santosh Shukla]

On 26 August 2014 17:33, Anders Roxell  wrote:
> On 2014-08-26 12:37, Santosh Shukla wrote:
>> On 26 August 2014 01:02, Anders Roxell  wrote:
>> > Remove dead initialisation.
>> >
>> > Signed-off-by: Anders Roxell 
>> > ---
>> >  test/api_test/odp_ring_test.c | 6 --
>> >  1 file changed, 6 deletions(-)
>> >
>> > diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
>> > index 6c2642e..93bd869 100644
>> > --- a/test/api_test/odp_ring_test.c
>> > +++ b/test/api_test/odp_ring_test.c
>> > @@ -103,7 +103,6 @@ static int test_ring_basic(odp_ring_t *r)
>> >
>> > printf("enqueue MAX_BULK objs\n");
>> > ret = odp_ring_sp_enqueue_burst(r, cur_src, MAX_BULK);
>> > -   cur_src += MAX_BULK;
>> > if ((ret & ODP_RING_SZ_MASK) != MAX_BULK) {
>> > ODP_ERR("sp_enq for %d obj failed\n", MAX_BULK);
>> > goto fail;
>> > @@ -160,7 +159,6 @@ static int test_ring_basic(odp_ring_t *r)
>> > }
>> > printf("enqueue MAX_BULK objs\n");
>> > ret = odp_ring_mp_enqueue_bulk(r, cur_src, MAX_BULK);
>> > -   cur_src += MAX_BULK;
>> > if (ret != 0) {
>> > ODP_ERR("mp_enq for %d obj failed\n", MAX_BULK);
>> > goto fail;
>> > @@ -192,9 +190,6 @@ static int test_ring_basic(odp_ring_t *r)
>> > goto fail;
>> > }
>> >
>> > -   cur_src = src;
>> > -   cur_dst = dst;
>> > -
>>
>> Rest of looks fine to me except above.. why you want to remove them?
>
> because they are not needed... if you look in the file before and after
> you will see them again 4 lines down...

Yes.
>
>
>>
>> If above change reverted then Reviewed-by : Santosh Shukla
>> 
>>
>>
>> > printf("test watermark and default bulk enqueue / dequeue\n");
>> > odp_ring_set_water_mark(r, 20);
>> > num_elems = 16;
>
> if the diff showed more you would see them here as well... and this one
> I didn't remove...

I didn't understood above.
>
>> > @@ -209,7 +204,6 @@ static int test_ring_basic(odp_ring_t *r)
>> > goto fail;
>> > }
>> > ret = odp_ring_mp_enqueue_bulk(r, cur_src, num_elems);
>> > -   cur_src += num_elems;
>> > if (ret != -EDQUOT) {
>> > ODP_ERR("Watermark not exceeded\n");
>> > goto fail;
>> > --
>> > 1.9.1
>> >
>> >
>> > ___
>> > 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

Re: [lng-odp] [PATCH] test/api_test/odp_ring_test.c: clear clang warning

[Santosh Shukla]

On 26 August 2014 01:02, Anders Roxell  wrote:
> Remove dead initialisation.
>
> Signed-off-by: Anders Roxell 
> ---
>  test/api_test/odp_ring_test.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
> index 6c2642e..93bd869 100644
> --- a/test/api_test/odp_ring_test.c
> +++ b/test/api_test/odp_ring_test.c
> @@ -103,7 +103,6 @@ static int test_ring_basic(odp_ring_t *r)
>
> printf("enqueue MAX_BULK objs\n");
> ret = odp_ring_sp_enqueue_burst(r, cur_src, MAX_BULK);
> -   cur_src += MAX_BULK;
> if ((ret & ODP_RING_SZ_MASK) != MAX_BULK) {
> ODP_ERR("sp_enq for %d obj failed\n", MAX_BULK);
> goto fail;
> @@ -160,7 +159,6 @@ static int test_ring_basic(odp_ring_t *r)
> }
> printf("enqueue MAX_BULK objs\n");
> ret = odp_ring_mp_enqueue_bulk(r, cur_src, MAX_BULK);
> -   cur_src += MAX_BULK;
> if (ret != 0) {
> ODP_ERR("mp_enq for %d obj failed\n", MAX_BULK);
> goto fail;
> @@ -192,9 +190,6 @@ static int test_ring_basic(odp_ring_t *r)
> goto fail;
> }
>
> -   cur_src = src;
> -   cur_dst = dst;
> -

Rest of looks fine to me except above.. why you want to remove them?

If above change reverted then Reviewed-by : Santosh Shukla



> printf("test watermark and default bulk enqueue / dequeue\n");
> odp_ring_set_water_mark(r, 20);
> num_elems = 16;
> @@ -209,7 +204,6 @@ static int test_ring_basic(odp_ring_t *r)
> goto fail;
> }
> ret = odp_ring_mp_enqueue_bulk(r, cur_src, num_elems);
> -   cur_src += num_elems;
> if (ret != -EDQUOT) {
> ODP_ERR("Watermark not exceeded\n");
> goto fail;
> --
> 1.9.1
>
>
> ___
> 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

Re: [lng-odp] Regarding ODP rings in linux-generic

[Santosh Shukla]

Can you pl. share some (if possible) minimal sample app hitting race
condition. That will be helpful.

Thanks.

On 22 August 2014 17:19, Prashant Upadhyaya
 wrote:
> Hi Maxim,
>
> I don't pass any flags at the moment i.e. flags=0 at the time of 
> odp_ring_create.
>
> I did check the include/helper/odp_ring.h and it mentions --
> *   An OR of the following:
>  *- RING_F_SP_ENQ: If this flag is set, the default behavior when
>  *  using ``odp_ring_enqueue()`` or ``odp_ring_enqueue_bulk()``
>  *  is "single-producer". Otherwise, it is "multi-producers".
>  *- RING_F_SC_DEQ: If this flag is set, the default behavior when
>  *  using ``odp_ring_dequeue()`` or ``odp_ring_dequeue_bulk()``
>  *  is "single-consumer". Otherwise, it is "multi-consumers".
>
> So I suppose I am using multi-producers and multi-consumers, isn't it.
> At any rate, I am using the functions explicitly which are internally called 
> by the normal enq/deq functions
> odp_ring_mp_enqueue_bulk [I am indeed a multi producer]
> odp_ring_sc_dequeue_bulk  [I am indeed a single consumer]
>
> Regards
> -Prashant
>
>
>
> -Original Message-
> From: lng-odp-boun...@lists.linaro.org 
> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim Uvarov
> Sent: Friday, August 22, 2014 2:38 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Regarding ODP rings in linux-generic
>
> Hi Prashant,
>
> do you pass flags to odp_ring_create that it's multi consumer, multi producer?
>
> Maxim.
>
> On 08/22/2014 12:12 PM, Prashant Upadhyaya wrote:
>>
>> Hi,
>>
>> I have a usecase where each core has a ring associated with it.
>>
>> Every core dequeues from its own ring - thus each core's ring above is
>> representing the single consumer mode.
>>
>> Every core can enqueue to every other core's ring - thus each core's
>> ring above is representing the multi-producer mode.
>>
>> To enqueue, I use odp_ring_mp_enqueue_bulk
>>
>> To dequeue, I use odp_ring_sc_dequeue_bulk
>>
>> I try to enqueue in a loop till the enqueue succeeds, the idea being
>> that the other cores will dequeue eventually to create space on the
>> ring. I use fixed size rings.
>>
>> Now when I run my usecase, which has a lot of pipelining between
>> cores, I see that sometimes the code, which is enqueueing on a ring,
>> blocks in the loop i.e. its enqueue never succeeds.
>>
>> If I use my own locks to protect the enqueue and dequeue on a given
>> core's ring, then my usecase works fine.
>>
>> Now then, I have not yet been able to get to the bottom of this and
>> can't exactly put a finger on where the bug lies in the ring
>> framework, but the fact that my own external locking vanishes the
>> problem, I am inclined to believe that there seems to be some race
>> condition in rings implementation when there are multi producers and a
>> single consumer.
>>
>> I am not getting enough time to run some standalone stress tests to
>> reproduce the above issue in a controlled environment for further
>> debugging.
>>
>> If anybody on the list volunteers to test the above or has encountered
>> a similar problem, we probably have a chance to debug and fix this issue.
>>
>> Regards
>>
>> -Prashant
>>
>>
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended
>> solely for the use of the individual to whom it is addressed. It may
>> contain privileged or confidential information and should not be
>> circulated or used for any purpose other than for what it is intended.
>> If you have received this message in error, please notify the
>> originator immediately. If you are not the intended recipient, you are
>> notified that you are strictly prohibited from using, copying,
>> altering, or disclosing the contents of this message. Aricent accepts
>> no responsibility for loss or damage arising from the use of the
>> information transmitted by this email including damage from virus."
>>
>>
>> ___
>> 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
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely 
> for the use of the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be circulated or used 
> for any purpose other than for what it is intended. If you have received this 
> message in error, please notify the originator immediately. If you are not 
> the intended recipient, you are notified that you are strictly prohibited 
> from using, copying, altering, or disclosing the contents of this message. 
> Aricent accepts no responsibility for loss or damage arising from the use of 
> the information transmitted by this email including damage from virus."
>
> ___
> lng-odp mailing list
> lng

Re: [lng-odp] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

On 21 August 2014 17:42, Ola Liljedahl  wrote:
> If one ODP implementation automatically enables promiscuous mode on network
> interfaces, I think we might get different semantics on those targets (can't
> rely on external switches to do all filtering for you). If this is a
> work-around because we cannot get pktgen to use the intended destination
> addresses in packets, we are fixing the problem in the wrong end.

I could agree what you pointed out and Venky did mentioned that He
couldn't able to figure out a way in dpdk-pktgen.. so this is a
workaround However this discussion brought out need for set of few
api's in odp like enable/disable_promiscuous_mode(), link_status(),
setting multicaste etc..


>
>
> On 21 August 2014 13:08, Maxim Uvarov  wrote:
>>
>> On 08/21/2014 01:33 PM, Santosh Shukla wrote:
>>>
>>> On 21 August 2014 14:57, Venkatesh Vivekanandan
>>>
>>>  wrote:
>>>>
>>>>
>>>>
>>>> On 21 August 2014 14:27, Santosh Shukla 
>>>> wrote:
>>>>>
>>>>> On 21 August 2014 14:24, Ola Liljedahl 
>>>>> wrote:
>>>>>>
>>>>>> You are not always setting promiscuous mode on network interfaces in
>>>>>> ODP/linux-dpdk? Promiscuous mode should only be enabled when the
>>>>>> application
>>>>>> requires it. The l2fwd (is this the DPDK port? "passthrough" would be
>>>>>> a
>>>>>> better name) application could have a command line option which
>>>>>> requests
>>>>>> promiscuous mode on the used network interfaces.
>>>>>>
>>>>> Even better. Make sense to me. I'll spin the patch and do the changes
>>>>> in l2fwd cli interface accordingly.
>>>>>
>>>> There is no way one can pass the command line parameters to the
>>>> implementation currently, once that gets in then we can make it a user
>>>> configurable parameter. For now, we don't have a choice other than
>>>> keeping
>>>> them enabled.
>>>>
>>> I said that so keeping Mike's patch of odp_init_global agrument
>>> passing from App till linux-generic.. apllicable to dpdk too.
>>>
>>> This patch ""[PATCH] Add-global_init-paramiters
>>>
>>> Any other reason in your mind?
>>
>>
>> I think it should work well. For there is no need to have public API to
>> set up promisc mode. Due to main goal is Soc hw  abstraction.
>>
>>
>>
>>>
>>>
>>>>>> On 21 August 2014 08:57, Santosh Shukla 
>>>>>> wrote:
>>>>>>>
>>>>>>> Noticed that enabling promiscous mode helps l2fwd application work
>>>>>>> with
>>>>>>> pktgen
>>>>>>> or dpdk-pktgen
>>>>>>>
>>>>>>> Suggested-by: Venkatesh Vivekanandan
>>>>>>> 
>>>>>>> Signed-off-by: Santosh Shukla 
>>>>>>> ---
>>>>>>>   platform/linux-dpdk/odp_packet_dpdk.c |3 +++
>>>>>>>   1 file changed, 3 insertions(+)
>>>>>>>
>>>>>>> diff --git a/platform/linux-dpdk/odp_packet_dpdk.c
>>>>>>> b/platform/linux-dpdk/odp_packet_dpdk.c
>>>>>>> index d5c8e80..92edac5 100644
>>>>>>> --- a/platform/linux-dpdk/odp_packet_dpdk.c
>>>>>>> +++ b/platform/linux-dpdk/odp_packet_dpdk.c
>>>>>>> @@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk,
>>>>>>> const
>>>>>>> char *netdev,
>>>>>>>  ODP_DBG("dpdk tx queue setup done\n");
>>>>>>>  }
>>>>>>>
>>>>>>> +   /* Enable promiscous mode */
>>>>>>> +   rte_eth_promiscuous_enable(portid);
>>>>>>> +
>>>>>>>  /* Start device */
>>>>>>>  ret = rte_eth_dev_start(portid);
>>>>>>>  if (ret < 0)
>>>>>>> --
>>>>>>> 1.7.9.5
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> 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 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

Re: [lng-odp] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

On 21 August 2014 15:47, Venkatesh Vivekanandan
 wrote:
>
>
>
> On 21 August 2014 15:16, Ola Liljedahl  wrote:
>>
>> This command line option would be interpreted by the application. But the
>> application needs a function for setting an interface (pktio instance) in
>> promiscuous mode. Yet another missing piece of API.
>>
> Yes, we don't have say odp_pktio_promisc_enable/disable(). This is what I
> was talking about in yesterday's call as, we miss a bunch of functions in
> supporting the network interface. I will send out a list of functions that
> we might need.

That list nothing device capability or ethtool Ops :) in general as
discussed in chat with you. Ola, is this what your referring too?

>
>>
>>
>> On 21 August 2014 11:27, Venkatesh Vivekanandan
>>  wrote:
>>>
>>>
>>>
>>>
>>> On 21 August 2014 14:27, Santosh Shukla 
>>> wrote:
>>>>
>>>> On 21 August 2014 14:24, Ola Liljedahl  wrote:
>>>> > You are not always setting promiscuous mode on network interfaces in
>>>> > ODP/linux-dpdk? Promiscuous mode should only be enabled when the
>>>> > application
>>>> > requires it. The l2fwd (is this the DPDK port? "passthrough" would be
>>>> > a
>>>> > better name) application could have a command line option which
>>>> > requests
>>>> > promiscuous mode on the used network interfaces.
>>>> >
>>>>
>>>> Even better. Make sense to me. I'll spin the patch and do the changes
>>>> in l2fwd cli interface accordingly.
>>>>
>>> There is no way one can pass the command line parameters to the
>>> implementation currently, once that gets in then we can make it a user
>>> configurable parameter. For now, we don't have a choice other than keeping
>>> them enabled.
>>>
>>>>
>>>> >
>>>> > On 21 August 2014 08:57, Santosh Shukla 
>>>> > wrote:
>>>> >>
>>>> >> Noticed that enabling promiscous mode helps l2fwd application work
>>>> >> with
>>>> >> pktgen
>>>> >> or dpdk-pktgen
>>>> >>
>>>> >> Suggested-by: Venkatesh Vivekanandan
>>>> >> 
>>>> >> Signed-off-by: Santosh Shukla 
>>>> >> ---
>>>> >>  platform/linux-dpdk/odp_packet_dpdk.c |3 +++
>>>> >>  1 file changed, 3 insertions(+)
>>>> >>
>>>> >> diff --git a/platform/linux-dpdk/odp_packet_dpdk.c
>>>> >> b/platform/linux-dpdk/odp_packet_dpdk.c
>>>> >> index d5c8e80..92edac5 100644
>>>> >> --- a/platform/linux-dpdk/odp_packet_dpdk.c
>>>> >> +++ b/platform/linux-dpdk/odp_packet_dpdk.c
>>>> >> @@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk,
>>>> >> const
>>>> >> char *netdev,
>>>> >> ODP_DBG("dpdk tx queue setup done\n");
>>>> >> }
>>>> >>
>>>> >> +   /* Enable promiscous mode */
>>>> >> +   rte_eth_promiscuous_enable(portid);
>>>> >> +
>>>> >> /* Start device */
>>>> >> ret = rte_eth_dev_start(portid);
>>>> >> if (ret < 0)
>>>> >> --
>>>> >> 1.7.9.5
>>>> >>
>>>> >>
>>>> >> ___
>>>> >> 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

Re: [lng-odp] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

On 21 August 2014 15:16, Ola Liljedahl  wrote:
> This command line option would be interpreted by the application. But the
> application needs a function for setting an interface (pktio instance) in
> promiscuous mode. Yet another missing piece of API.
>

What else required for existing pktio instance to operate on
promiscuous mode other than sending a hint to driver. For example, The
way I look at it per existing code, all I need to pass one promiscuous
mode hint in case of dpdk, dpdk implementation api (which is this -
rte_eth_promiscuous_enable();) will do the rest for me. Like to know
more.. Thanks.

>
> On 21 August 2014 11:27, Venkatesh Vivekanandan
>  wrote:
>>
>>
>>
>>
>> On 21 August 2014 14:27, Santosh Shukla  wrote:
>>>
>>> On 21 August 2014 14:24, Ola Liljedahl  wrote:
>>> > You are not always setting promiscuous mode on network interfaces in
>>> > ODP/linux-dpdk? Promiscuous mode should only be enabled when the
>>> > application
>>> > requires it. The l2fwd (is this the DPDK port? "passthrough" would be a
>>> > better name) application could have a command line option which
>>> > requests
>>> > promiscuous mode on the used network interfaces.
>>> >
>>>
>>> Even better. Make sense to me. I'll spin the patch and do the changes
>>> in l2fwd cli interface accordingly.
>>>
>> There is no way one can pass the command line parameters to the
>> implementation currently, once that gets in then we can make it a user
>> configurable parameter. For now, we don't have a choice other than keeping
>> them enabled.
>>
>>>
>>> >
>>> > On 21 August 2014 08:57, Santosh Shukla 
>>> > wrote:
>>> >>
>>> >> Noticed that enabling promiscous mode helps l2fwd application work
>>> >> with
>>> >> pktgen
>>> >> or dpdk-pktgen
>>> >>
>>> >> Suggested-by: Venkatesh Vivekanandan
>>> >> 
>>> >> Signed-off-by: Santosh Shukla 
>>> >> ---
>>> >>  platform/linux-dpdk/odp_packet_dpdk.c |3 +++
>>> >>  1 file changed, 3 insertions(+)
>>> >>
>>> >> diff --git a/platform/linux-dpdk/odp_packet_dpdk.c
>>> >> b/platform/linux-dpdk/odp_packet_dpdk.c
>>> >> index d5c8e80..92edac5 100644
>>> >> --- a/platform/linux-dpdk/odp_packet_dpdk.c
>>> >> +++ b/platform/linux-dpdk/odp_packet_dpdk.c
>>> >> @@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk,
>>> >> const
>>> >> char *netdev,
>>> >> ODP_DBG("dpdk tx queue setup done\n");
>>> >> }
>>> >>
>>> >> +   /* Enable promiscous mode */
>>> >> +   rte_eth_promiscuous_enable(portid);
>>> >> +
>>> >> /* Start device */
>>> >> ret = rte_eth_dev_start(portid);
>>> >> if (ret < 0)
>>> >> --
>>> >> 1.7.9.5
>>> >>
>>> >>
>>> >> ___
>>> >> 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

Re: [lng-odp] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

On 21 August 2014 14:57, Venkatesh Vivekanandan
 wrote:
>
>
>
> On 21 August 2014 14:27, Santosh Shukla  wrote:
>>
>> On 21 August 2014 14:24, Ola Liljedahl  wrote:
>> > You are not always setting promiscuous mode on network interfaces in
>> > ODP/linux-dpdk? Promiscuous mode should only be enabled when the
>> > application
>> > requires it. The l2fwd (is this the DPDK port? "passthrough" would be a
>> > better name) application could have a command line option which requests
>> > promiscuous mode on the used network interfaces.
>> >
>>
>> Even better. Make sense to me. I'll spin the patch and do the changes
>> in l2fwd cli interface accordingly.
>>
> There is no way one can pass the command line parameters to the
> implementation currently, once that gets in then we can make it a user
> configurable parameter. For now, we don't have a choice other than keeping
> them enabled.
>

I said that so keeping Mike's patch of odp_init_global agrument
passing from App till linux-generic.. apllicable to dpdk too.

This patch ""[PATCH] Add-global_init-paramiters

Any other reason in your mind?


>>
>> >
>> > On 21 August 2014 08:57, Santosh Shukla 
>> > wrote:
>> >>
>> >> Noticed that enabling promiscous mode helps l2fwd application work with
>> >> pktgen
>> >> or dpdk-pktgen
>> >>
>> >> Suggested-by: Venkatesh Vivekanandan
>> >> 
>> >> Signed-off-by: Santosh Shukla 
>> >> ---
>> >>  platform/linux-dpdk/odp_packet_dpdk.c |3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/platform/linux-dpdk/odp_packet_dpdk.c
>> >> b/platform/linux-dpdk/odp_packet_dpdk.c
>> >> index d5c8e80..92edac5 100644
>> >> --- a/platform/linux-dpdk/odp_packet_dpdk.c
>> >> +++ b/platform/linux-dpdk/odp_packet_dpdk.c
>> >> @@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk,
>> >> const
>> >> char *netdev,
>> >> ODP_DBG("dpdk tx queue setup done\n");
>> >> }
>> >>
>> >> +   /* Enable promiscous mode */
>> >> +   rte_eth_promiscuous_enable(portid);
>> >> +
>> >> /* Start device */
>> >> ret = rte_eth_dev_start(portid);
>> >> if (ret < 0)
>> >> --
>> >> 1.7.9.5
>> >>
>> >>
>> >> ___
>> >> 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

Re: [lng-odp] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

On 21 August 2014 14:24, Ola Liljedahl  wrote:
> You are not always setting promiscuous mode on network interfaces in
> ODP/linux-dpdk? Promiscuous mode should only be enabled when the application
> requires it. The l2fwd (is this the DPDK port? "passthrough" would be a
> better name) application could have a command line option which requests
> promiscuous mode on the used network interfaces.
>

Even better. Make sense to me. I'll spin the patch and do the changes
in l2fwd cli interface accordingly.

>
> On 21 August 2014 08:57, Santosh Shukla  wrote:
>>
>> Noticed that enabling promiscous mode helps l2fwd application work with
>> pktgen
>> or dpdk-pktgen
>>
>> Suggested-by: Venkatesh Vivekanandan 
>> Signed-off-by: Santosh Shukla 
>> ---
>>  platform/linux-dpdk/odp_packet_dpdk.c |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/platform/linux-dpdk/odp_packet_dpdk.c
>> b/platform/linux-dpdk/odp_packet_dpdk.c
>> index d5c8e80..92edac5 100644
>> --- a/platform/linux-dpdk/odp_packet_dpdk.c
>> +++ b/platform/linux-dpdk/odp_packet_dpdk.c
>> @@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk, const
>> char *netdev,
>> ODP_DBG("dpdk tx queue setup done\n");
>> }
>>
>> +   /* Enable promiscous mode */
>> +   rte_eth_promiscuous_enable(portid);
>> +
>> /* Start device */
>> ret = rte_eth_dev_start(portid);
>> if (ret < 0)
>> --
>> 1.7.9.5
>>
>>
>> ___
>> 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] [PATCH] linux-dpdk: Enable promiscous mode

[Santosh Shukla]

Noticed that enabling promiscous mode helps l2fwd application work with pktgen
or dpdk-pktgen

Suggested-by: Venkatesh Vivekanandan 
Signed-off-by: Santosh Shukla 
---
 platform/linux-dpdk/odp_packet_dpdk.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/platform/linux-dpdk/odp_packet_dpdk.c 
b/platform/linux-dpdk/odp_packet_dpdk.c
index d5c8e80..92edac5 100644
--- a/platform/linux-dpdk/odp_packet_dpdk.c
+++ b/platform/linux-dpdk/odp_packet_dpdk.c
@@ -135,6 +135,9 @@ int setup_pkt_dpdk(pkt_dpdk_t * const pkt_dpdk, const char 
*netdev,
ODP_DBG("dpdk tx queue setup done\n");
}
 
+   /* Enable promiscous mode */
+   rte_eth_promiscuous_enable(portid);
+
/* Start device */
ret = rte_eth_dev_start(portid);
if (ret < 0)
-- 
1.7.9.5


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

Re: [lng-odp] FIXME, TODO and todo in ODP src files

[Santosh Shukla]

On 21 August 2014 05:31, Mike Holmes  wrote:
> All,
>
> How do we plan to track and clean up all the todo items ?
> Doxygen can track items in the files it is exposed to (i.e. the public .h)
> but only if @todo is used, those are built nightly and appear here
> http://docs.opendataplane.org/html/todo.html
>
> But for all the other code we are generating quite a list of untracked
> things.
> Should we ban todo and say they must be logged as bugs before the code can
> be accepted ?

By following it up :) , Your right by some method to follow-up.

>
> I particularly like these two :)
> " @todo This is a serious hack to allow us to use packet ..."
> " euwww.. FIXME"

I will take care above "euwww" one. thanks

>
> Mike
>
> ./test/api_test/odp_timer_ping.c: * euwww.. FIXME ..
> ./test/api_test/odp_timer_ping.c: * FIXME..
> ./test/api_test/odp_ring_test.c: taken care inside func : todo */);
> ./test/api_test/odp_ring_test.c: taken care inside func : todo */);
> ./platform/linux-dpdk/include/odp_buffer_internal.h:/* TODO: move these to
> correct files */
> ./platform/linux-generic/odp_packet_netmap.c:#define ETH_PROMISC  1 /* TODO:
> maybe this should be exported to the user */
> ./platform/linux-generic/odp_packet_netmap.c: /* TODO: This seems to cause
> the app to not receive frames
> ./platform/linux-generic/include/odp_buffer_internal.h:/* TODO: move these
> to correct files */
> ./platform/linux-generic/odp_crypto.c: * @todo This is a serious hack to
> allow us to use packet buffer to convey
> ./platform/linux-generic/odp_schedule.c:/* TODO: random or queue based
> selection */
> ./platform/linux-generic/odp_schedule.c: * TODO: SYNC_ORDERED not
> implemented yet
> ./platform/linux-keystone2/include/odp_buffer_internal.h:/* TODO: move these
> to correct files */
> ./platform/linux-keystone2/odp_shared_memory.c: * FIXME: mapping_id is
> uint32_t.
> ./platform/linux-keystone2/odp_buffer_pool.c: * FIXME: Currently a number of
> HW descriptors is limited,
> ./platform/linux-keystone2/odp_buffer_pool.c: /* FIXME: Need to define error
> codes somewhere */
> ./platform/linux-keystone2/odp_buffer_pool.c: * TODO: Need to get descriptor
> size here and shift
> ./platform/linux-keystone2/odp_buffer_pool.c: /* TODO: pslen is set to 0,
> but should be configurable */
> ./platform/linux-keystone2/odp_queue.c: * TODO: HW queue is mapped dirrectly
> to queue_entry_t
> ./platform/linux-keystone2/odp_queue.c: * TODO: Should this series of
> buffers be enqueued atomically?
> ./platform/linux-keystone2/odp_queue.c: /* TODO: Implement multi dequeue a
> lower level */
> ./platform/linux-keystone2/odp_queue.c: /* TODO: Implement multi dequeue a
> lower level */
> ./platform/linux-keystone2/odp_packet_io.c: /* FIXME: Here rx/tx channels
> should be closed */
> ./platform/linux-keystone2/odp_packet_io.c: * FIXME: IT is a kind of WA for
> current ODP API usage.
> ./platform/linux-keystone2/odp_packet_io.c: * TODO: Remove it when PA will
> be used.
> ./include/helper/odp_eth.h: * @todo Check usage of tpid vs ethertype. Check
> outer VLAN TPID.
> ./include/helper/odp_ring.h: * @param socket_id (dummy, not included : todo)
> ./include/odp_crypto.h: * @todo Add "odp_session_proc_info_t"
> ./include/odp_crypto.h: * @todo Clarify who zero's ICV and how this relates
> to "hash_result_offset"
> ./include/odp_crypto.h: * @todo Resolve if completion_event is necessary,
> can/should the output
> ./include/odp_crypto.h: * @todo Define the implication of the use_entropy
> parameter
> ./example/packet_netmap/odp_pktio_netmap.c: /** TODO: find a way to
> associate private data with pktios */
> ./example/generator/odp_generator.c: /* TODO This should be changed to use
> an
> ./example/generator/odp_generator.c: /* TODO use odp timer */
> ./example/generator/odp_generator.c: /* TODO use odp timer */
> ./example/generator/odp_generator.c: /* TODO This should be changed to use
> an
>
>
> --
> Mike Holmes
> Linaro Technical Manager / Lead
> 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

Re: [lng-odp] [PATCH v2 1/1] API support for querying mac address

[Santosh Shukla]

On 20 August 2014 14:59, Balasubramanian Manoharan
 wrote:
> This patch provides API support for querying mac address of an interface 
> using odp_pktio_t handle.
> This current patch incorporates the review comments from the previous patch.
>
> The discussions are ongoing regarding adding additional API for querying mac 
> address using device name, once it gets finalized the same will be provided 
> as a different patch.
>
> Signed-off-by: Balasubramanian Manoharan 
> ---

Patch won't pass checkpatch; Pl. take care that.

>  include/odp_packet_io.h|  8 +++
>  platform/linux-generic/include/odp_packet_netmap.h |  1 +
>  platform/linux-generic/odp_packet_io.c | 28 
> +-
>  platform/linux-generic/odp_packet_netmap.c |  4 +++-
>  platform/linux-generic/odp_packet_socket.c | 20 +---
>  5 files changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/include/odp_packet_io.h b/include/odp_packet_io.h
> index cfefac0..6c06520 100644
> --- a/include/odp_packet_io.h
> +++ b/include/odp_packet_io.h
> @@ -129,6 +129,14 @@ void odp_pktio_set_input(odp_packet_t pkt, odp_pktio_t 
> id);
>   */
>  odp_pktio_t odp_pktio_get_input(odp_packet_t pkt);
>
> +/**
> + * Get mac address of the interface
> + *
> + * @param id   ODP packet IO handle
> + * @param mac_addr Storage for Mac address of the packet IO interface 
> (filled by function)
> + * @return  0 on success or -1 on error
> +**/
> +int odp_pktio_get_mac_addr(odp_pktio_t id, unsigned char* mac_addr);
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
> b/platform/linux-generic/include/odp_packet_netmap.h
> index 57d9f2c..3693416 100644
> --- a/platform/linux-generic/include/odp_packet_netmap.h
> +++ b/platform/linux-generic/include/odp_packet_netmap.h
> @@ -40,6 +40,7 @@ typedef struct {
> odp_queue_t tx_access; /* Used for exclusive access to send packets */
> uint32_t if_flags;
> char ifname[32];
> +   unsigned char if_mac[ETH_ALEN];
>  } pkt_netmap_t;
>
>  /**
> diff --git a/platform/linux-generic/odp_packet_io.c 
> b/platform/linux-generic/odp_packet_io.c
> index 33ade10..f644dff 100644
> --- a/platform/linux-generic/odp_packet_io.c
> +++ b/platform/linux-generic/odp_packet_io.c
> @@ -245,7 +245,7 @@ odp_pktio_t odp_pktio_open(const char *dev, 
> odp_buffer_pool_t pool,
> ODP_ERR("This type of I/O is not supported. Please 
> recompile.\n");
> break;
> }
> -
> +   pktio_entry->s.params.type = params->type;
> unlock_entry(pktio_entry);
> return id;
>  }
> @@ -535,3 +535,29 @@ int pktin_deq_multi(queue_entry_t *qentry, 
> odp_buffer_hdr_t *buf_hdr[], int num)
>
> return nbr;
>  }
> +int odp_pktio_get_mac_addr(odp_pktio_t pkt, unsigned char* mac_addr){
> +
> +   pktio_entry_t * pktio_entry = get_entry(pkt);
> +   if(!pktio_entry){
> +   ODP_ERR("Invalid odp_pktio_t value\n");
> +   return -1;
> +   }
> +   switch(pktio_entry->s.params.type){
> +   case ODP_PKTIO_TYPE_SOCKET_BASIC:
> +   case ODP_PKTIO_TYPE_SOCKET_MMSG:
> +   memcpy(mac_addr, pktio_entry->s.pkt_sock.if_mac, 
> ETH_ALEN);
> +   break;
> +   case ODP_PKTIO_TYPE_SOCKET_MMAP:
> +   memcpy(mac_addr, pktio_entry->s.pkt_sock_mmap.if_mac, 
> ETH_ALEN);
> +   break;
> +#ifdef ODP_HAVE_NETMAP
> +   case ODP_PKTIO_TYPE_NETMAP:
> +   memcpy(mac_addr, pktio_entry->s.pkt_nm.if_mac, 
> ETH_ALEN);
> +   break;
> +#endif
> +   default:
> +   ODP_ERR("Invalid pktio type: %02x\n", 
> pktio_entry->s.params.type);
> +   return ODP_PKTIO_INVALID;
> +   }
> +   return 0;
> +}
> diff --git a/platform/linux-generic/odp_packet_netmap.c 
> b/platform/linux-generic/odp_packet_netmap.c
> index e2215ab..9bf2fcf 100644
> --- a/platform/linux-generic/odp_packet_netmap.c
> +++ b/platform/linux-generic/odp_packet_netmap.c
> @@ -222,9 +222,11 @@ int setup_pkt_netmap(pkt_netmap_t * const pkt_nm, const 
> char *netdev,
> ODP_ERR("Error: token creation failed\n");
> return -1;
> }
> +   if( socket_store_hw_addr(pkt_nm->if_mac, netdev)
> +return -1;
>
> odp_queue_enq(pkt_nm->tx_access, token);
> -
> +
> ODP_DBG("Wait for link to come up\n");
> sleep(WAITLINK_TMO);
> ODP_DBG("Done\n");
> diff --git a/platform/linux-generic/odp_packet_socket.c 
> b/platform/linux-generic/odp_packet_socket.c
> index d44c333..a40fe60 100644
> --- a/platform/linux-generic/odp_packet_socket.c
> +++ b/platform/linux-generic/odp_packet_socket.c
> @@ -57,6 +57,9 @@ typedef struct {
>
>  static raw_socket_t raw_sockets[MAX_RAW_SOCKETS_NETDEVS];
>  static odp_spi

Re: [lng-odp] [PATCH 1/1] API support to get mac address of an interface using odp_pktio_t

[Santosh Shukla]

On 19 August 2014 11:46, Bala Manoharan  wrote:
> Hi Santosh,
>
>
> if (socket_store_hw_addr())
>   return -1;
>
>>>> We cannot use this since the return value for error will be changed to
>>>> -1 and not zero in the future.
> I have kept this as of now since I believe petri is changing the #defines
> for different error scenarios.
>
> We have to check the return value using the following snippet,
> if(ODP_PKTIO_INVALID != socket_store_hw_addr()){
>   return -1;
> }

Fine, then write explicit comment on top about your assumption. Thanks.
>
>
> On 19 August 2014 11:40, Santosh Shukla  wrote:
>>
>> On 19 August 2014 11:26, Balasubramanian Manoharan
>>  wrote:
>> > Regards,
>> > Bala
>>
>> this is bad :) add proper description.
>>
>> do git commit --amend
>> - remove above and add relevant description.
>> - save it, then review with "git log"
>>
>> > Signed-off-by: Balasubramanian Manoharan 
>> > ---
>> >  include/odp_packet_io.h|  8 +++
>> >  platform/linux-generic/include/odp_packet_netmap.h |  1 +
>> >  platform/linux-generic/odp_packet_io.c | 28
>> > +-
>> >  platform/linux-generic/odp_packet_netmap.c |  4 +++-
>> >  platform/linux-generic/odp_packet_socket.c |  8 +++
>> >  5 files changed, 43 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/include/odp_packet_io.h b/include/odp_packet_io.h
>> > index cfefac0..6c06520 100644
>> > --- a/include/odp_packet_io.h
>> > +++ b/include/odp_packet_io.h
>> > @@ -129,6 +129,14 @@ void odp_pktio_set_input(odp_packet_t pkt,
>> > odp_pktio_t id);
>> >   */
>> >  odp_pktio_t odp_pktio_get_input(odp_packet_t pkt);
>> >
>> > +/**
>> > + * Get mac address of the interface
>> > + *
>> > + * @param id   ODP packet IO handle
>> > + * @param mac_addr Storage for Mac address of the packet IO
>> > interface (filled by function)
>> > + * @return  0 on success or -1 on error
>> > +**/
>> > +int odp_pktio_get_mac_addr(odp_pktio_t id, unsigned char* mac_addr);
>> >  #ifdef __cplusplus
>> >  }
>> >  #endif
>> > diff --git a/platform/linux-generic/include/odp_packet_netmap.h
>> > b/platform/linux-generic/include/odp_packet_netmap.h
>> > index 57d9f2c..3693416 100644
>> > --- a/platform/linux-generic/include/odp_packet_netmap.h
>> > +++ b/platform/linux-generic/include/odp_packet_netmap.h
>> > @@ -40,6 +40,7 @@ typedef struct {
>> > odp_queue_t tx_access; /* Used for exclusive access to send
>> > packets */
>> > uint32_t if_flags;
>> > char ifname[32];
>> > +   unsigned char if_mac[ETH_ALEN];
>> >  } pkt_netmap_t;
>> >
>> >  /**
>> > diff --git a/platform/linux-generic/odp_packet_io.c
>> > b/platform/linux-generic/odp_packet_io.c
>> > index 33ade10..069b0e1 100644
>> > --- a/platform/linux-generic/odp_packet_io.c
>> > +++ b/platform/linux-generic/odp_packet_io.c
>> > @@ -245,7 +245,7 @@ odp_pktio_t odp_pktio_open(const char *dev,
>> > odp_buffer_pool_t pool,
>> > ODP_ERR("This type of I/O is not supported. Please
>> > recompile.\n");
>> > break;
>> > }
>> > -
>> > +   pktio_entry->s.params.type = params->type;
>> > unlock_entry(pktio_entry);
>> > return id;
>> >  }
>> > @@ -535,3 +535,29 @@ int pktin_deq_multi(queue_entry_t *qentry,
>> > odp_buffer_hdr_t *buf_hdr[], int num)
>> >
>> > return nbr;
>> >  }
>> > +int odp_pktio_get_mac_addr(odp_pktio_t pkt, unsigned char* mac_addr){
>> > +
>> > +   pktio_entry_t * pktio_entry = get_entry(pkt);
>> > +   if(!pktio_entry){
>> > +   printf("Invalid odp_pktio_t value\n");
>> > +   return ODP_PKTIO_INVALID;
>> > +   }
>> > +   switch(pktio_entry->s.params.type){
>> > +   case ODP_PKTIO_TYPE_SOCKET_BASIC:
>> > +   case ODP_PKTIO_TYPE_SOCKET_MMSG:
>> > +   memcpy(mac_addr, pktio_entry->s.pkt_sock.if_mac,
>> > ETH_ALEN);
>> > +   break;
>> > +   case ODP_PKTIO_TYPE_SOCKET_MMAP:
>> > +   memcpy(mac_addr,
&g

Re: [lng-odp] [PATCH 1/1] API support to get mac address of an interface using odp_pktio_t

[Santosh Shukla]

On 19 August 2014 11:26, Balasubramanian Manoharan
 wrote:
> Regards,
> Bala

this is bad :) add proper description.

do git commit --amend
- remove above and add relevant description.
- save it, then review with "git log"

> Signed-off-by: Balasubramanian Manoharan 
> ---
>  include/odp_packet_io.h|  8 +++
>  platform/linux-generic/include/odp_packet_netmap.h |  1 +
>  platform/linux-generic/odp_packet_io.c | 28 
> +-
>  platform/linux-generic/odp_packet_netmap.c |  4 +++-
>  platform/linux-generic/odp_packet_socket.c |  8 +++
>  5 files changed, 43 insertions(+), 6 deletions(-)
>
> diff --git a/include/odp_packet_io.h b/include/odp_packet_io.h
> index cfefac0..6c06520 100644
> --- a/include/odp_packet_io.h
> +++ b/include/odp_packet_io.h
> @@ -129,6 +129,14 @@ void odp_pktio_set_input(odp_packet_t pkt, odp_pktio_t 
> id);
>   */
>  odp_pktio_t odp_pktio_get_input(odp_packet_t pkt);
>
> +/**
> + * Get mac address of the interface
> + *
> + * @param id   ODP packet IO handle
> + * @param mac_addr Storage for Mac address of the packet IO interface 
> (filled by function)
> + * @return  0 on success or -1 on error
> +**/
> +int odp_pktio_get_mac_addr(odp_pktio_t id, unsigned char* mac_addr);
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
> b/platform/linux-generic/include/odp_packet_netmap.h
> index 57d9f2c..3693416 100644
> --- a/platform/linux-generic/include/odp_packet_netmap.h
> +++ b/platform/linux-generic/include/odp_packet_netmap.h
> @@ -40,6 +40,7 @@ typedef struct {
> odp_queue_t tx_access; /* Used for exclusive access to send packets */
> uint32_t if_flags;
> char ifname[32];
> +   unsigned char if_mac[ETH_ALEN];
>  } pkt_netmap_t;
>
>  /**
> diff --git a/platform/linux-generic/odp_packet_io.c 
> b/platform/linux-generic/odp_packet_io.c
> index 33ade10..069b0e1 100644
> --- a/platform/linux-generic/odp_packet_io.c
> +++ b/platform/linux-generic/odp_packet_io.c
> @@ -245,7 +245,7 @@ odp_pktio_t odp_pktio_open(const char *dev, 
> odp_buffer_pool_t pool,
> ODP_ERR("This type of I/O is not supported. Please 
> recompile.\n");
> break;
> }
> -
> +   pktio_entry->s.params.type = params->type;
> unlock_entry(pktio_entry);
> return id;
>  }
> @@ -535,3 +535,29 @@ int pktin_deq_multi(queue_entry_t *qentry, 
> odp_buffer_hdr_t *buf_hdr[], int num)
>
> return nbr;
>  }
> +int odp_pktio_get_mac_addr(odp_pktio_t pkt, unsigned char* mac_addr){
> +
> +   pktio_entry_t * pktio_entry = get_entry(pkt);
> +   if(!pktio_entry){
> +   printf("Invalid odp_pktio_t value\n");
> +   return ODP_PKTIO_INVALID;
> +   }
> +   switch(pktio_entry->s.params.type){
> +   case ODP_PKTIO_TYPE_SOCKET_BASIC:
> +   case ODP_PKTIO_TYPE_SOCKET_MMSG:
> +   memcpy(mac_addr, pktio_entry->s.pkt_sock.if_mac, 
> ETH_ALEN);
> +   break;
> +   case ODP_PKTIO_TYPE_SOCKET_MMAP:
> +   memcpy(mac_addr, pktio_entry->s.pkt_sock_mmap.if_mac, 
> ETH_ALEN);
> +   break;
> +#ifdef ODP_HAVE_NETMAP
> +   case ODP_PKTIO_TYPE_NETMAP:
> +   memcpy(mac_addr, pktio_entry->s.pkt_nm.if_mac, 
> ETH_ALEN);
> +   break;
> +#endif
> +   default:
> +   ODP_ERR("Invalid pktio type: %02x\n", 
> pktio_entry->s.params.type);
> +   return ODP_PKTIO_INVALID;
> +   }
> +   return 0;
> +}
> diff --git a/platform/linux-generic/odp_packet_netmap.c 
> b/platform/linux-generic/odp_packet_netmap.c
> index e2215ab..e9e9f56 100644
> --- a/platform/linux-generic/odp_packet_netmap.c
> +++ b/platform/linux-generic/odp_packet_netmap.c
> @@ -222,9 +222,11 @@ int setup_pkt_netmap(pkt_netmap_t * const pkt_nm, const 
> char *netdev,
> ODP_ERR("Error: token creation failed\n");
> return -1;
> }
> +   if( 0 != socket_store_hw_addr(pkt_nm->if_mac, netdev)
> +return -1;

if (socket_store_hw_addr())
  return -1;

>
> odp_queue_enq(pkt_nm->tx_access, token);
> -
> +

Why?
> ODP_DBG("Wait for link to come up\n");
> sleep(WAITLINK_TMO);
> ODP_DBG("Done\n");
> diff --git a/platform/linux-generic/odp_packet_socket.c 
> b/platform/linux-generic/odp_packet_socket.c
> index d44c333..d96aa8e 100644
> --- a/platform/linux-generic/odp_packet_socket.c
> +++ b/platform/linux-generic/odp_packet_socket.c
> @@ -735,7 +735,7 @@ static int mmap_bind_sock(pkt_sock_mmap_t *pkt_sock, 
> const char *netdev)
> return 0;
>  }
>
> -static int mmap_store_hw_addr(pkt_sock_mmap_t * const pkt_sock,
> +static int socket_store_hw_addr(int sockfd,unsigned char * if_mac,
>   const char *netde

Re: [lng-odp] [PATCH 2/2] isolation: disable default odp cpuset

[Santosh Shukla]

On 18 August 2014 19:42, Stuart Haslam  wrote:
> On Mon, Aug 18, 2014 at 12:32:36PM +0100, Santosh Shukla wrote:
>> On 18 August 2014 16:30, Stuart Haslam  wrote:
>> > On Mon, Aug 18, 2014 at 08:41:45AM +0100, Santosh Shukla wrote:
>> >> - Disable default odp thread cpuset. Use is-cpu-isolated.sh script to 
>> >> create
>> >>   cpuset for dplane, cplane for odp.
>> >> - Use odp-on-isolated-cpu.sh script to test this application.
>> >> - test script location [1]
>> >>
>> >> - Refer readme for instruction to use.
>> >>
>> >> [1]
>> >> https://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2
>> >>
>> >> Signed-off-by: Santosh Shukla 
>> >> ---
>> >>  example/isolation/odp_isolation.c  |5 +
>> >>  example/isolation/readme   |   20 
>> >>  platform/linux-generic/odp_linux.c |   12 ++--
>> >>  3 files changed, 35 insertions(+), 2 deletions(-)
>> >>  create mode 100644 example/isolation/readme
>> >>
>> >> diff --git a/example/isolation/odp_isolation.c 
>> >> b/example/isolation/odp_isolation.c
>> >> index 8d8fffc..1ade4c7 100644
>> >> --- a/example/isolation/odp_isolation.c
>> >> +++ b/example/isolation/odp_isolation.c
>> >> @@ -214,6 +214,11 @@ int main(int argc, char *argv[])
>> >>   thr_id = odp_thread_create(0);
>> >>   odp_init_local(thr_id);
>> >>
>> >> + /*
>> >> +  * create dummy dp thread and don't pin them on any core,
>> >> +  * use odp-on-isolated-cpu.sh script to define dplane cpuset
>> >> +  * and to pin, run app on them, Refer readme.
>> >> +  */
>> >>   for (i=0; i> >>
>> >>   first_core = atoi(args.core_name[i]);
>> >> diff --git a/example/isolation/readme b/example/isolation/readme
>> >> new file mode 100644
>> >> index 000..d49d61a
>> >> --- /dev/null
>> >> +++ b/example/isolation/readme
>> >> @@ -0,0 +1,20 @@
>> >> +
>> >> +README on How-to run odp app on isolated core for no_hz_full kernel mode.
>> >> +
>> >> +- Disbale timer init in odp application.
>> >> +- avoid using odp's cpuset. Let odp thread launch unpinned.
>> >> +- use odp-on-isolated-cpu.sh script to pin odp dp thread to
>> >> + dplane cpuset.
>> >> +
>> >> +- download my local test-definition repo link [1]
>> >> +- copy odp_isolation binary to /usr/local/bin
>> >> +- run  ./common/scripts/odp-on-isolated-cpu.sh
>> >> +Or
>> >> +-  ./common/scripts/odp-on-isolated-cpu.sh 1,2 "odp_isolation -l 1,2"
>> >> +- Above script shows isolation duration, before / after interrupt count.
>> >> +
>> >> +Known issue :
>> >> +- x86 hw generates spurious ipi lead to break no_hz_full isolation 
>> >> (todo).
>> >> +
>> >> +[1] 
>> >> https://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2
>> >> +
>> >> diff --git a/platform/linux-generic/odp_linux.c 
>> >> b/platform/linux-generic/odp_linux.c
>> >> index 6e2b448..7e853c7 100644
>> >> --- a/platform/linux-generic/odp_linux.c
>> >> +++ b/platform/linux-generic/odp_linux.c
>> >> @@ -22,6 +22,11 @@
>> >>  #include 
>> >>
>> >>
>> >> +#define NO_HZ_FULL_ISOL /*
>> >> +  * don't use odp cpuset.
>> >> +  * enable this for odp isolation mode
>> >> +  */
>> >> +
>> >>  typedef struct {
>> >>   int thr_id;
>> >>   void *(*start_routine) (void *);
>> >> @@ -49,7 +54,9 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
>> >> *thread_tbl, int num,
>> >>   int first_core, void *(*start_routine) (void *), void *arg)
>> >>  {
>> >>   int i;
>> >> +#ifndef NO_HZ_FULL_ISOL
>> >>   cpu_set_t cpu_set;
>> >> +#endif
>> >>   odp_start_args_t *start_args;
>> >>   int core_count;
>> >>   int cpu;
>> >> @@ -62,16 +69,17 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
>> >> *thread_tbl, int num,
>> &

Re: [lng-odp] [PATCH 1/2] isolation : initial odp isolation example app

[Santosh Shukla]

On 18 August 2014 19:27, Stuart Haslam  wrote:
> On Mon, Aug 18, 2014 at 12:19:49PM +0100, Santosh Shukla wrote:
>> On 18 August 2014 16:30, Stuart Haslam  wrote:
>> > On Mon, Aug 18, 2014 at 08:41:00AM +0100, Santosh Shukla wrote:
>
>> >
>> > I'm not sure it's worth adding an example application that does nothing.
>> > Isolation is not be something the application needs explicit knowledge
>> > of so having an example app demonstrating it is a bit odd. All of the
>> > existing examples / tests should be capable of being run isolated.
>> >
>> > For this test you could start with odp_example as it has no dependencies
>>
>> Not entirely true and I did thought about using odp_example.
>> odp_example does use timer api (clock_gettime) which I don't want to
>> call from isolated thread. Therefore choose to keep dummy (explicitly
>> mentioned in writeup) thread looping for x time.
>>
>
> OK fair enough, so the odp_example would currently fail this test
> because there's a problem with the linu-generic implementation of the
> timers, this is a known issue and should be fixed at some point.

Keeping known limitation of this approach in mind. I agree :)

>
>> More appropriate test application is l2fwd, where I am doing isolation.
>>
>
> OK, can you send patches for that instead? :)

Yup.. I just finished uploading those patch set to my odp.git
repository link [1]. Primarily that git repo made for demo purpose
however most of em should go for review/feedback.

[1] https://git.linaro.org/people/santosh.shukla/odp.git

[P.S: pl. ignore cruel hack done at top most patch, It was for demo.
also due design limitation in existing global_init_dpdk() function..
Its one of use-case for "global_init" generic argument passing
discussion happened last week, Assuming that Mikey working on it so
didn't paid much attention.]

>
>> There is a readme (in next patch) which very much informs NOT to use
>> odp method of cpuset for thread pinning instead use script.
>
> Yeah I read that - it doesn't say why not though.

Hmm.. I 'll make it more clear in readme -:)
>
>> I could
>> choose to add job enqueue/dequeue in while loop But in next patch.
>
> I don't think that's the right direction to head. Given that any of the
> tests or examples should be capable of running isolated, if we were to
> have a specific isolation test then it would just end up replicating all
> of the other tests. It would be better to just run the existing tests
> on isolated cores. As you say that's not possible at the minute, but it
> should be a goal - and the easiest way to start is by picking an
> existing test that does work on isolated cores.
>

Fair enough. dpdk-s-port-for-odp-l2fwd works!! My scope of work to
make one *existing* application demoable for no_hz_full isolation. As
you said, Yes we should target and introduce isolation specific hints
in framework to make other application work seamlessly.

>> >
>> > I wonder if changing odp_linux_pthread_create to take an array of cores
>> > rather than just the first core is a better way to go. A quick grep
>> > through the existing examples / tests shows almost all callers provide 1
>> > for the number of cores, so it's not currently being used as expected.
>> >
>>
>> Nope. Not in this case, I want to create thread on any of cores based
>> on arg_list, That may be look like this -
>> -l 2,3,5,6 OR -l 3,5,6,7
>>
>> Also changing the order helps me to test my isolation script.
>>
>
> Yes, what I was suggesting would make that easier. Instead of looping
> over num_workers and setting first_core and num for each iteration you
> just pass in an array of core numbers that you want threads started on,
> e.g.;
>
> odp_linux_pthread_create(thread_tbl, num_workers, args.core_num,
>  run_thread, NULL);
>
> Where args.core_num is just what you currently have as args.core_name
> but stored as an integer.
>
even better. Sorry for confusion.

In summary, Does it make sense to keep this dummy app alive in odp? As
I iterated that Its very handy app for me to test randomize order for
"any core number pinning to any thread" and In future, there might be
possibility [Which Ola mentioned in RT vs Isolation discussion last
week] of one core two threads or many threads. In such case, It make
sense to me to keep this app alive and keep maturing it will
combination of use-cases like 1 cpu :: 2 Threads etc.. Again a test
example for isolation but much handy to test.. no setup dependency
like l2fwd etc..

> --
> Stuart.
>

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

Re: [lng-odp] [PATCH 2/2] isolation: disable default odp cpuset

[Santosh Shukla]

On 18 August 2014 16:30, Stuart Haslam  wrote:
> On Mon, Aug 18, 2014 at 08:41:45AM +0100, Santosh Shukla wrote:
>> - Disable default odp thread cpuset. Use is-cpu-isolated.sh script to create
>>   cpuset for dplane, cplane for odp.
>> - Use odp-on-isolated-cpu.sh script to test this application.
>> - test script location [1]
>>
>> - Refer readme for instruction to use.
>>
>> [1]
>> https://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2
>>
>> Signed-off-by: Santosh Shukla 
>> ---
>>  example/isolation/odp_isolation.c  |5 +
>>  example/isolation/readme   |   20 
>>  platform/linux-generic/odp_linux.c |   12 ++--
>>  3 files changed, 35 insertions(+), 2 deletions(-)
>>  create mode 100644 example/isolation/readme
>>
>> diff --git a/example/isolation/odp_isolation.c 
>> b/example/isolation/odp_isolation.c
>> index 8d8fffc..1ade4c7 100644
>> --- a/example/isolation/odp_isolation.c
>> +++ b/example/isolation/odp_isolation.c
>> @@ -214,6 +214,11 @@ int main(int argc, char *argv[])
>>   thr_id = odp_thread_create(0);
>>   odp_init_local(thr_id);
>>
>> + /*
>> +  * create dummy dp thread and don't pin them on any core,
>> +  * use odp-on-isolated-cpu.sh script to define dplane cpuset
>> +  * and to pin, run app on them, Refer readme.
>> +  */
>>   for (i=0; i>
>>   first_core = atoi(args.core_name[i]);
>> diff --git a/example/isolation/readme b/example/isolation/readme
>> new file mode 100644
>> index 000..d49d61a
>> --- /dev/null
>> +++ b/example/isolation/readme
>> @@ -0,0 +1,20 @@
>> +
>> +README on How-to run odp app on isolated core for no_hz_full kernel mode.
>> +
>> +- Disbale timer init in odp application.
>> +- avoid using odp's cpuset. Let odp thread launch unpinned.
>> +- use odp-on-isolated-cpu.sh script to pin odp dp thread to
>> + dplane cpuset.
>> +
>> +- download my local test-definition repo link [1]
>> +- copy odp_isolation binary to /usr/local/bin
>> +- run  ./common/scripts/odp-on-isolated-cpu.sh
>> +Or
>> +-  ./common/scripts/odp-on-isolated-cpu.sh 1,2 "odp_isolation -l 1,2"
>> +- Above script shows isolation duration, before / after interrupt count.
>> +
>> +Known issue :
>> +- x86 hw generates spurious ipi lead to break no_hz_full isolation (todo).
>> +
>> +[1] 
>> https://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2
>> +
>> diff --git a/platform/linux-generic/odp_linux.c 
>> b/platform/linux-generic/odp_linux.c
>> index 6e2b448..7e853c7 100644
>> --- a/platform/linux-generic/odp_linux.c
>> +++ b/platform/linux-generic/odp_linux.c
>> @@ -22,6 +22,11 @@
>>  #include 
>>
>>
>> +#define NO_HZ_FULL_ISOL /*
>> +  * don't use odp cpuset.
>> +  * enable this for odp isolation mode
>> +  */
>> +
>>  typedef struct {
>>   int thr_id;
>>   void *(*start_routine) (void *);
>> @@ -49,7 +54,9 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
>> *thread_tbl, int num,
>>   int first_core, void *(*start_routine) (void *), void *arg)
>>  {
>>   int i;
>> +#ifndef NO_HZ_FULL_ISOL
>>   cpu_set_t cpu_set;
>> +#endif
>>   odp_start_args_t *start_args;
>>   int core_count;
>>   int cpu;
>> @@ -62,16 +69,17 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
>> *thread_tbl, int num,
>>   memset(thread_tbl, 0, num * sizeof(odp_linux_pthread_t));
>>
>>   for (i = 0; i < num; i++) {
>> + cpu = (first_core + i) % core_count;
>> +#ifndef NO_HZ_FULL_ISOL
>>   pthread_attr_init(&thread_tbl[i].attr);
>>
>>   CPU_ZERO(&cpu_set);
>>
>> - cpu = (first_core + i) % core_count;
>>   CPU_SET(cpu, &cpu_set);
>>
>>   pthread_attr_setaffinity_np(&thread_tbl[i].attr,
>>   sizeof(cpu_set_t), &cpu_set);
>> -
>> +#endif
>
> There's no need for this to be a compile time decision - this changes
> the behaviour of all applications linked against this library.
>

Agree, There might be better way to avoid linkage issue.

> I would rather leave the affinity setting in odp_linux_pthread_create
> and let the script just ensure that the specified 

Re: [lng-odp] [PATCH 1/2] isolation : initial odp isolation example app

[Santosh Shukla]

On 18 August 2014 16:30, Stuart Haslam  wrote:
> On Mon, Aug 18, 2014 at 08:41:00AM +0100, Santosh Shukla wrote:
>> Test application to run odp dummy dp thread
>> on no_hz_full kernel mode for few seconds.
>>
>> - Create 2 threads, running in loop for few seconds.
>> - Mask timer thread.
>>
>> Signed-off-by: Santosh Shukla 
>> ---
>> Note :
>> - Patch set based on Maxim's v2 patch under discussion
>> "implement-odp_init_global-init-mask.patch"
>> - Open for review feedback however wont merge due
>>   above dependancy.
>> - More isolation specific changes seen at
>> https://git.linaro.org/people/santosh.shukla/odp.git
>>
>>  configure.ac  |1 +
>>  example/Makefile.am   |2 +-
>>  example/isolation/Makefile.am |5 +
>>  example/isolation/odp_isolation.c |  232 
>> +
>>  4 files changed, 239 insertions(+), 1 deletion(-)
>>  create mode 100644 example/isolation/Makefile.am
>>  create mode 100644 example/isolation/odp_isolation.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index 74713a7..2b6758b 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -142,6 +142,7 @@ AC_CONFIG_FILES([Makefile
>>example/packet/Makefile
>>example/packet_netmap/Makefile
>>example/timer/Makefile
>> +  example/isolation/Makefile
>>test/Makefile
>>test/api_test/Makefile
>>pkgconfig/libodp.pc])
>> diff --git a/example/Makefile.am b/example/Makefile.am
>> index 01a3305..4cb4a23 100644
>> --- a/example/Makefile.am
>> +++ b/example/Makefile.am
>> @@ -1 +1 @@
>> -SUBDIRS = generator l2fwd odp_example packet packet_netmap timer
>> +SUBDIRS = generator l2fwd odp_example packet packet_netmap timer isolation
>> diff --git a/example/isolation/Makefile.am b/example/isolation/Makefile.am
>> new file mode 100644
>> index 000..7e39773
>> --- /dev/null
>> +++ b/example/isolation/Makefile.am
>> @@ -0,0 +1,5 @@
>> +include $(top_srcdir)/example/Makefile.inc
>> +
>> +bin_PROGRAMS = odp_isolation
>> +
>> +dist_odp_isolation_SOURCES = odp_isolation.c
>> diff --git a/example/isolation/odp_isolation.c 
>> b/example/isolation/odp_isolation.c
>> new file mode 100644
>> index 000..8d8fffc
>> --- /dev/null
>> +++ b/example/isolation/odp_isolation.c
>> @@ -0,0 +1,232 @@
>> +/* Copyright (c) 2013, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +/**
>> + * @file
>> + *
>> + * @example  odp_isol_test.c ODP isolation example application
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +/* ODP main header */
>> +#include 
>> +
>> +/* ODP helper for Linux apps */
>> +#include 
>> +
>> +/* GNU lib C */
>> +#include 
>> +
>> +#define MAX_WORKERS  32  /**< Max worker threads */
>> +
>> +/**
>> + * Parsed command line application arguments
>> + */
>> +typedef struct {
>> + int core_count; /**< Core count*/
>> + char **core_name;   /**< Array of pointers to core name */
>> +} appl_args_t;
>> +
>> +/**
>> + * @internal Print help
>> + */
>> +static void print_usage(void)
>> +{
>> + printf("\n\nUsage: ./odp_isolation [options]\n");
>> + printf("Options:\n");
>> + printf("  -l, --cpulist \n");
>> + printf("  -h, --help  this help\n");
>> + printf("\n\n");
>> +}
>> +
>> +/**
>> + * @internal Worker thread
>> + *
>> + * @param arg  Arguments
>> + *
>> + * @return NULL on failure
>> + */
>> +static void *run_thread(void *arg)
>> +{
>> + int thr;
>> + unsigned long long tick = 0;
>> + int counter = 0;
>> +
>> + thr = odp_thread_id();
>> +
>> + printf("Thread %i starts on core %i\n", thr, odp_thread_core());
>> +
>> + /* loop for some duration then exit */
>> + do {
>> + tick++;
>> +
>> + if (tick > 1000) {
>> +
>> + tick = 0;
>> + counter++;
>> + }
>> +
>> + if (counter == 1000)
>> + break;
>> + } while (1);
>>

[lng-odp] [PATCH 1/2] isolation : initial odp isolation example app

[Santosh Shukla]

Test application to run odp dummy dp thread
on no_hz_full kernel mode for few seconds.

- Create 2 threads, running in loop for few seconds.
- Mask timer thread.

Signed-off-by: Santosh Shukla 
---
Note :
- Patch set based on Maxim's v2 patch under discussion
"implement-odp_init_global-init-mask.patch"
- Open for review feedback however wont merge due
  above dependancy.
- More isolation specific changes seen at
https://git.linaro.org/people/santosh.shukla/odp.git

 configure.ac  |1 +
 example/Makefile.am   |2 +-
 example/isolation/Makefile.am |5 +
 example/isolation/odp_isolation.c |  232 +
 4 files changed, 239 insertions(+), 1 deletion(-)
 create mode 100644 example/isolation/Makefile.am
 create mode 100644 example/isolation/odp_isolation.c

diff --git a/configure.ac b/configure.ac
index 74713a7..2b6758b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,6 +142,7 @@ AC_CONFIG_FILES([Makefile
 example/packet/Makefile
 example/packet_netmap/Makefile
 example/timer/Makefile
+example/isolation/Makefile
 test/Makefile
 test/api_test/Makefile
 pkgconfig/libodp.pc])
diff --git a/example/Makefile.am b/example/Makefile.am
index 01a3305..4cb4a23 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator l2fwd odp_example packet packet_netmap timer
+SUBDIRS = generator l2fwd odp_example packet packet_netmap timer isolation
diff --git a/example/isolation/Makefile.am b/example/isolation/Makefile.am
new file mode 100644
index 000..7e39773
--- /dev/null
+++ b/example/isolation/Makefile.am
@@ -0,0 +1,5 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_isolation
+
+dist_odp_isolation_SOURCES = odp_isolation.c
diff --git a/example/isolation/odp_isolation.c 
b/example/isolation/odp_isolation.c
new file mode 100644
index 000..8d8fffc
--- /dev/null
+++ b/example/isolation/odp_isolation.c
@@ -0,0 +1,232 @@
+/* Copyright (c) 2013, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example  odp_isol_test.c ODP isolation example application
+ */
+
+#include 
+#include 
+
+/* ODP main header */
+#include 
+
+/* ODP helper for Linux apps */
+#include 
+
+/* GNU lib C */
+#include 
+
+#define MAX_WORKERS32  /**< Max worker threads */
+
+/**
+ * Parsed command line application arguments
+ */
+typedef struct {
+   int core_count; /**< Core count*/
+   char **core_name;   /**< Array of pointers to core name */
+} appl_args_t;
+
+/**
+ * @internal Print help
+ */
+static void print_usage(void)
+{
+   printf("\n\nUsage: ./odp_isolation [options]\n");
+   printf("Options:\n");
+   printf("  -l, --cpulist \n");
+   printf("  -h, --help  this help\n");
+   printf("\n\n");
+}
+
+/**
+ * @internal Worker thread
+ *
+ * @param arg  Arguments
+ *
+ * @return NULL on failure
+ */
+static void *run_thread(void *arg)
+{
+   int thr;
+   unsigned long long tick = 0;
+   int counter = 0;
+
+   thr = odp_thread_id();
+
+   printf("Thread %i starts on core %i\n", thr, odp_thread_core());
+
+   /* loop for some duration then exit */
+   do {
+   tick++;
+
+   if (tick > 1000) {
+
+   tick = 0;
+   counter++;
+   }
+
+   if (counter == 1000)
+   break;
+   } while (1);
+
+   return arg;
+}
+
+/**
+ * @internal Parse arguments
+ *
+ * @param argc  Argument count
+ * @param argv  Argument vector
+ * @param args  Test arguments
+ */
+static void parse_args(int argc, char *argv[], appl_args_t *args)
+{
+   int opt;
+   int long_index;
+   char *names, *str, *token, *save;
+   size_t len;
+   int i;
+
+   static struct option longopts[] = {
+   {"cpulists", required_argument, NULL, 'l'}, /* return 'l' */
+   {"help", no_argument, NULL, 'h'}, /* return 'h' */
+   {NULL, 0, NULL, 0}
+   };
+
+   while (1) {
+   opt = getopt_long(argc, argv, "+l:h", longopts, &long_index);
+
+   if (opt == -1)
+   break;  /* No more options */
+
+   switch (opt) {
+   case 'l':
+   len = strlen(optarg);
+   if (len == 0) {
+   print_usage();
+   exit(EXIT_FAILURE);
+   }
+   len += 1;   /* add room for '\0' */
+
+   names = malloc(len);
+   if (names == NULL) {

[lng-odp] [PATCH 2/2] isolation: disable default odp cpuset

[Santosh Shukla]

- Disable default odp thread cpuset. Use is-cpu-isolated.sh script to create
  cpuset for dplane, cplane for odp.
- Use odp-on-isolated-cpu.sh script to test this application.
- test script location [1]

- Refer readme for instruction to use.

[1]
https://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2

Signed-off-by: Santosh Shukla 
---
 example/isolation/odp_isolation.c  |5 +
 example/isolation/readme   |   20 
 platform/linux-generic/odp_linux.c |   12 ++--
 3 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 example/isolation/readme

diff --git a/example/isolation/odp_isolation.c 
b/example/isolation/odp_isolation.c
index 8d8fffc..1ade4c7 100644
--- a/example/isolation/odp_isolation.c
+++ b/example/isolation/odp_isolation.c
@@ -214,6 +214,11 @@ int main(int argc, char *argv[])
thr_id = odp_thread_create(0);
odp_init_local(thr_id);
 
+   /*
+* create dummy dp thread and don't pin them on any core,
+* use odp-on-isolated-cpu.sh script to define dplane cpuset
+* and to pin, run app on them, Refer readme.
+*/
for (i=0; ihttps://git.linaro.org/people/santosh.shukla/test-definitions.git/shortlog/refs/heads/isol-v2
+
diff --git a/platform/linux-generic/odp_linux.c 
b/platform/linux-generic/odp_linux.c
index 6e2b448..7e853c7 100644
--- a/platform/linux-generic/odp_linux.c
+++ b/platform/linux-generic/odp_linux.c
@@ -22,6 +22,11 @@
 #include 
 
 
+#define NO_HZ_FULL_ISOL /*
+* don't use odp cpuset.
+* enable this for odp isolation mode
+*/
+
 typedef struct {
int thr_id;
void *(*start_routine) (void *);
@@ -49,7 +54,9 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
*thread_tbl, int num,
int first_core, void *(*start_routine) (void *), void *arg)
 {
int i;
+#ifndef NO_HZ_FULL_ISOL
cpu_set_t cpu_set;
+#endif
odp_start_args_t *start_args;
int core_count;
int cpu;
@@ -62,16 +69,17 @@ void odp_linux_pthread_create(odp_linux_pthread_t 
*thread_tbl, int num,
memset(thread_tbl, 0, num * sizeof(odp_linux_pthread_t));
 
for (i = 0; i < num; i++) {
+   cpu = (first_core + i) % core_count;
+#ifndef NO_HZ_FULL_ISOL
pthread_attr_init(&thread_tbl[i].attr);
 
CPU_ZERO(&cpu_set);
 
-   cpu = (first_core + i) % core_count;
CPU_SET(cpu, &cpu_set);
 
pthread_attr_setaffinity_np(&thread_tbl[i].attr,
sizeof(cpu_set_t), &cpu_set);
-
+#endif
start_args = malloc(sizeof(odp_start_args_t));
memset(start_args, 0, sizeof(odp_start_args_t));
start_args->start_routine = start_routine;
-- 
1.7.9.5


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

Re: [lng-odp] [PATCH 1/1] ODP-DPDK multi-queue support

[Santosh Shukla]

On 13 August 2014 15:26, Maxim Uvarov  wrote:
> On 08/13/2014 12:36 PM, Venkatesh Vivekanandan wrote:
>>
>>
>>
>>
>> On 13 August 2014 02:30, Wiles, Roger Keith > <mailto:keith.wi...@windriver.com>> wrote:
>>
>> The DPDK version of Pktgen is a bit easy to use and configure then
>> the kernel based version. You can also run it on the machine if
>> you make sure you configure DPDK correctly (if you have two DPDKs
>> running).
>>
>> If you build Pktgen-DPDK on another machine it should be pretty
>> quick (within a 1/2 hour normally if not faster :-) ) to get
>> running if all you need is to send UDP or TCP frames. I still not
>> know your requires for the traffic. At least with Pktgen-DPDK you
>> have a clean simple full screen ASCII (vt100) interface to use.
>>
>>
>> I am modifying the dst ip address. Say 12 different ip address(201.0.0.0
>> to 201.0.0.11) and again start from beginning. Can you please point me to
>> how pktgen can do this?.
>
>
> with odp generator it has to be easy:

(:-

I think, we should stop using odp_generator, It simply doesn't work
for case basis. Sticking with in-kernel pktgen or dpdk-pktgen better
option for testing/regression.

> example/generator/odp_generator.c
> static void pack_udp_pkt(odp_buffer_t obuf)
> {
>
> change this:
> ip->dst_addr = odp_cpu_to_be_32(args->appl.dstip);
>
> to something like this:
> ip->dst_addr = odp_cpu_to_be_32(0xc900 + (i++ % 12))
>
>
> Maxim.
>>
>>
>>
>> If you have the machine setup for DPDK it will just work sending
>> 64Byte frames as 10G wire rate. If you decide to go this direction
>> I can help set it up for you.
>>
>> *Keith **Wiles*, Principal Technologist with CTO office, *Wind
>> River*mobile 972-213-5533
>>
>> On Aug 12, 2014, at 3:41 PM, Maxim Uvarov > <mailto:maxim.uva...@linaro.org>> wrote:
>>
>>> On 08/13/2014 12:38 AM, Mike Holmes wrote:
>>>>
>>>> To generate test data we don't have to use ODP, although we
>>>> should try to do that down the road, but equally you still need
>>>> to use external tools to be sure you did not make compatible
>>>> only with yourself mistakes.
>>>>
>>>> I was wondering why we can't spawn several process on one
>>>> machine that all send to the same port to test this ?
>>>
>>>
>>> Why not to use kernel packet generator?
>>> https://www.kernel.org/doc/Documentation/networking/pktgen.txt
>>>
>>>>
>>>>
>>>> On 12 August 2014 16:31, Maxim Uvarov >>> <mailto:maxim.uva...@linaro.org><mailto:maxim.uva...@linaro.org>>
>>>> wrote:
>>>>
>>>>On 08/13/2014 12:29 AM, Maxim Uvarov wrote:
>>>>
>>>>why not to use tcpreplay?
>>>>
>>>>I.e. odp+libpcap+dpdk+tcpreplay if we have everything ready?
>>>>
>>>>Maxim.
>>>>
>>>>Ah, I should check that first. tcpreplay doesn't depend on
>>>> libpcap.
>>>>
>>>>ldd /usr/bin/tcpreplay
>>>>linux-vdso.so.1 =>  (0x7fffa3bfe000)
>>>>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>>>> (0x7f3d490ba000)
>>>>/lib64/ld-linux-x86-64.so.2 (0x7f3d494a5000)
>>>>
>>>>
>>>>
>>>>
>>>>On 08/12/2014 11:42 PM, Wiles, Roger Keith wrote:
>>>>
>>>>Pktgen has a number of different ways to send packets
>>>>single, range, pcap or random, sequence with parameters.
>>>>
>>>>One thing Pktgen does not do is act like a real
>>>> stack, but
>>>>you can simulate that with pcap or sequence packets. It
>>>>basically depends on how complex a data flow you need.
>>>>
>>>># git clonegit://github.com/Pktgen/Pktgen-DPDK
>>>><http://github.com/Pktgen/Pktgen-DPDK>
>>>>
>>>>Let me know if I can help or change the code in some way.
>>>>
>>>>THanks
>>>>++keith
>>>>
>>>>    *Keith **Wiles*, Principal Technologist wi

Re: [lng-odp] [PATCH 1/1] ODP-DPDK multi-queue support

[Santosh Shukla]

On 12 August 2014 23:38, Mike Holmes  wrote:
> So it looks like we don't have any way to test this without an Ixia which is
> a problem given that Santosh is having trouble.
> Basically there is no CI job to point at that shows that excluding human
> error it is still working as expected.
>

Status :

Yesterday with Venky's help I managed to get dpdk-pktgen working with
odp l2fwd applivation for single queue patch. I have not tested multi
patch yet.

Refer bug [1] for details, I could see no_hz_full isolated
odp's-dpdk-l2fwd recieving/sending packet for more than 2000 secs.
In-kernel pktgen has problem with odp's-dpdk-l2fwd.

[1] https://bugs.linaro.org/show_bug.cgi?id=320

> Keith, is dpdk pktgen able to generate pkts in the way Venki needs ?
>
> Mike
>
>
> On 12 August 2014 02:17, Santosh Shukla  wrote:
>>
>> On 12 August 2014 00:25, Mike Holmes  wrote:
>> > Which test case in odp/test would check this, or does it need an
>> > application
>> > like l2fwd to be run - are either in LAVA/CI ?
>> >
>> > Santosh are you able to verify this does not break anything as part of
>> > the
>> > l2fwd work you are doing ?
>> >
>>
>> No, I am seeing problem with current and should persist in this multi
>> flavour too. We have bug reported on that lines. So whole dpdk-l2fwd
>> doesn't works for me for my requirement.
>>
>> Thanks.
>>
>> > Mike
>> >
>> >
>> > On 11 August 2014 01:43, Venkatesh Vivekanandan
>> >  wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On 9 August 2014 17:32, Mike Holmes  wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 8 August 2014 17:46, Anders Roxell 
>> >>> wrote:
>> >>>>
>> >>>> On 2014-08-08 17:31, Maxim Uvarov wrote:
>> >>>> > On 08/08/2014 05:13 PM, Venkatesh Vivekanandan wrote:
>> >>>> > >
>> >>>> > >
>> >>>> > >
>> >>>> > >On 7 August 2014 21:10, Anders Roxell > >>>> > ><mailto:anders.rox...@linaro.org>> wrote:
>> >>>> > >
>> >>>> > >On 2014-08-07 10:41, Mike Holmes wrote:
>> >>>> > >> Does this need a signoff by someone else before it is merged
>> >>>> > > ?
>> >>>> > >>
>> >>>> > >> I think we want to enforce getting an ack, tested-by or
>> >>>> > >reviewed-by before
>> >>>> > >> we merge things, we have informally moved that way over the
>> >>>> > > last
>> >>>> > >couple of
>> >>>> > >> weeks and now I think it is time we made it a formal
>> >>>> > > requirement.
>> >>>> > >
>> >>>> > >Agree.
>> >>>> > >
>> >>>> > >
>> >>>> > >If this is the case, then is it fair to say initial discussion of
>> >>>> > >24-hour window is void?. I guess Maxim was waiting for 2 days(for
>> >>>> > >any comments) before he could merge this patch. Do we have any
>> >>>> > >time-limit before which a patch /must /be reviewed or tested? I
>> >>>> > >hope we can't wait indefinitely or is this the case?.
>> >>>> >
>> >>>> > I think if patch came from platfrom maintainer, it's not new API.
>> >>>> > No
>> >>>> > comments in 1 or 2 days, than it's ok to merge it. If patch came
>> >>>> > from somobody alse I would ask maintainer to review it.
>> >>>>
>> >>>> I disagree with this.
>> >>>> No matter where the patch comes from and who wrote the patch, it can
>> >>>> be
>> >>>> wrong and need a second pair of eyes i.e.,
>> >>>> (Reviewed|Acked|Signed-off)-by.
>> >>>> If no one has replied to a patch after 2 days, the author of the
>> >>>> patch
>> >>>> should ping the list and maintainer.
>> >>>>
>> >>>> After the second pair of eyes, the patch should be ok to be merged.
>> >>>> The ODP maintainer should do a smoke build test on all the supported
>> >>>> platforms before merging tho

Re: [lng-odp] [PATCH 1/1] ODP-DPDK multi-queue support

[Santosh Shukla]

On 12 August 2014 00:25, Mike Holmes  wrote:
> Which test case in odp/test would check this, or does it need an application
> like l2fwd to be run - are either in LAVA/CI ?
>
> Santosh are you able to verify this does not break anything as part of the
> l2fwd work you are doing ?
>

No, I am seeing problem with current and should persist in this multi
flavour too. We have bug reported on that lines. So whole dpdk-l2fwd
doesn't works for me for my requirement.

Thanks.

> Mike
>
>
> On 11 August 2014 01:43, Venkatesh Vivekanandan
>  wrote:
>>
>>
>>
>>
>> On 9 August 2014 17:32, Mike Holmes  wrote:
>>>
>>>
>>>
>>>
>>> On 8 August 2014 17:46, Anders Roxell  wrote:

 On 2014-08-08 17:31, Maxim Uvarov wrote:
 > On 08/08/2014 05:13 PM, Venkatesh Vivekanandan wrote:
 > >
 > >
 > >
 > >On 7 August 2014 21:10, Anders Roxell >>> > >> wrote:
 > >
 > >On 2014-08-07 10:41, Mike Holmes wrote:
 > >> Does this need a signoff by someone else before it is merged ?
 > >>
 > >> I think we want to enforce getting an ack, tested-by or
 > >reviewed-by before
 > >> we merge things, we have informally moved that way over the
 > > last
 > >couple of
 > >> weeks and now I think it is time we made it a formal
 > > requirement.
 > >
 > >Agree.
 > >
 > >
 > >If this is the case, then is it fair to say initial discussion of
 > >24-hour window is void?. I guess Maxim was waiting for 2 days(for
 > >any comments) before he could merge this patch. Do we have any
 > >time-limit before which a patch /must /be reviewed or tested? I
 > >hope we can't wait indefinitely or is this the case?.
 >
 > I think if patch came from platfrom maintainer, it's not new API. No
 > comments in 1 or 2 days, than it's ok to merge it. If patch came
 > from somobody alse I would ask maintainer to review it.

 I disagree with this.
 No matter where the patch comes from and who wrote the patch, it can be
 wrong and need a second pair of eyes i.e.,
 (Reviewed|Acked|Signed-off)-by.
 If no one has replied to a patch after 2 days, the author of the patch
 should ping the list and maintainer.

 After the second pair of eyes, the patch should be ok to be merged.
 The ODP maintainer should do a smoke build test on all the supported
 platforms before merging though.
>>>
>>>
>>> My 2 cents
>>> We have started to develop a cohesive API, I think that is down to a lot
>>> of folks working together.
>>> I also think that peer review/team work is reflected in the increasing
>>> willingness to review each others patches which has improved quality
>>> and helped establish the guidelines on how things bolt together in ODP,
>>> may long discussions have spawned from patches.
>>>
>>> No one is beyond silly mistakes, peer review finds a lot of the dumb
>>> stuff for little cost, saving on the inevitable ugly patch up that will
>>> ensue otherwise.
>>> Maxim you could do the default reviews if no one came forward, but if a
>>> submitter finds and establishes their own network of reviewers that is one
>>> extra pair of eyes and ideas.
>>
>>
>> Can someone please review this patch?. If there is any comments, we can
>> request maxim to revert the patch, otherwise he can add the
>> "Reviewed-by/Tested-by" to the applied patch.
>>

 Cheers,
 Anders

 >
 > Maxim.
 >
 > > Anders
 > >
 > >>
 > >> Mike
 > >>
 > >>
 > >> On 7 August 2014 09:15, Maxim Uvarov >>> > >> wrote:
 > >>
 > >> > Merged, thanks!
 > >> >
 > >> > Maxim.
 > >> >
 > >> >
 > >> > On 08/05/2014 06:54 PM, venkatesh.vivekanan...@linaro.org
 > > wrote:
 > >> >
 > >> >> From: Venkatesh Vivekanandan
 > >>>> > >>
 > >> >>
 > >> >> - Multi queue support per interface is enabled.
 > >> >> - odp_pktio_send with "0" packet is called in odp_pktio_recv
 > > to
 > >> >>give the transmitted buffers back to mempool.
 > >> >> - mbuf alloc failure during receive is fixed by giving more
 > >buffers to
 > >> >>mempool.
 > >> >> - mempool cache size is given equivalent to MAX_PKT_BURST.
 > >> >>
 > >> >> Signed-off-by: Venkatesh Vivekanandan
 > >>>> > >>
 > >> >> ---
 > >> >> platform/linux-dpdk/include/odp_packet_dpdk.h |  24 +
 > >> >>   platform/linux-dpdk/odp_buffer_pool.c |   4 +-
 > >> >>   platform/linux-dpdk/odp_packet_dpdk.c | 136
 > >> >> +-
 > >> >>   platform/linux-dpdk/odp_packet_io.