Re: [lng-odp] odph_cuckoo_table_create not working with more than 8192 capacity

2018-08-03 Thread Bogdan Pricope
I think is a better practice to use configuration file instead of
modifying the template:

ODP_CONFIG_FILE= 

ODP_CONFIG_FILE=//odp/my_config.conf
./example/generator/odp_generator -I 1 -m r


$ cat ./my_config.conf
odp_implementation = "linux-generic"
config_file_version = "0.0.1"


queue_basic: {
# Maximum queue size. Value must be a power of two.
max_queue_size = 8192

# Default queue size. Value must be a power of two.
default_queue_size = 4096
}


On 3 August 2018 at 09:21, Elo, Matias (Nokia - FI/Espoo)
 wrote:
> Hi Daniel,
>
> The cuckoo table implementation is internally using plain queues, which have 
> by default
> a limited size of 8192 as you have noticed. You can increase this by changing
> ' queue_basic.max_queue_size' in config/odp-linux-generic.conf. The maximum 
> supported
> value is currently 1 048 576. After modifying the config you have to either 
> set
> ODP_CONFIG_FILE environment variable or do 'make clean && make'.
>
> Would this table be large enough for your use case? If not, we have to think 
> about updating
> the cuckoo table implementation.
>
> Regards,
> Matias
>
>
>> On 2 Aug 2018, at 21:31, Daniel Feferman  wrote:
>>
>> Hi all,
>>
>> I was using odph_cuckoo_table_create on version 19 and it seems the
>> capacity field can only take up to 8192, after that the function return
>> NULL (not able to create). Since capacity is set to a type uint32_t I was
>> not expecting this behavior, am I doing something wrong? Or the function is
>> really set to handle just 8192?
>>
>> Best,
>> Daniel
>


Re: [lng-odp] odp tools manpages

2018-06-05 Thread Bogdan Pricope
NAME
   odp_generator – generate or terminate IPv4 traffic

SYNOPSIS
   odp_generator OPTIONS

DESCRIPTION
   This ODP example application generates or terminate IPv4
traffic and outputs statistic prints at 20 s interval time

  Work mode:
-   generate UDP packets (‘u’ mode): IPv4 UDP packets are
generated with configured payload size, IP addresses, UDP ports, etc.
e.g.
  odp_generator -I  -m u --srcmac   --dstmac  --srcip  --dstip 

-   receive IPv4 packets (‘r’ mode): IPv4 packets are received at
highest rate.
e.g.
  odp_generator -I  -m r

-   generate/receive ICMP (ping) packets (‘p’ mode): requires two cores
e.g.
  odp_generator -I  -m p --srcmac  --dstmac  --srcip  --dstip  --cpumask 

Mandatory OPTIONS:

  -I, --interface Eth interfaces (comma-separated, no spaces)
  -m, --mode work mode: generate udp(u), receive(r), generate/receive icmp(p)
  -a, --srcmac  (‘udp’, ‘icmp’) Source MAC address
  -b, --dstmac (‘udp’, ‘icmp’) Destination MAC address
  -s, --srcip (‘udp’, ‘icmp’) Source IP address
  -d, --dstip (‘udp’, ‘icmp’) Destination IP address

Optional OPTIONS

  -h, --help   Display help and exit.
  -e, --srcport (‘udp’) Source UDP port
  -f, --dstport (‘udp’) Destination UDP port
  -p, --packetsize (‘udp’, ‘icmp’) Payload length of generated packets
  -t, --timeout (‘icmp’) Wait ICMP reply timeout seconds
  -i, --interval (‘udp’, ‘icmp’) Wait interval ms between sending each
packet burst
 default is 1000 ms. 0 for flood mode
  -w, --workers Specify number of workers to be assigned to application
 default is to assign all. On ‘icmp’ mode, number of
workers is forced to 2.
  -c, --cpumask Specify number of workers and distribution on cores as
hexadecimal value
  -n, --count (‘udp’, ‘icmp’) The number of packets to be generated
  -x, --udp_tx_burst (‘udp’) Size of UDP TX burst
  default is 16
  -r, --rx_burst (‘receive’) Size of RX burst
  default is 32
  -y, --csum Use platform checksum support if available
 default is disabled
  -z, --sched (‘receive’) Use scheduler API to receive packets instead
of direct mode API.
 default is direct mode API

On 5 June 2018 at 13:40, Bogdan Pricope  wrote:
> Start from 'help' option of odp_generator:
>
> # ./example/generator/odp_generator -h
>
> Usage: odp_generator OPTIONS
>   E.g. odp_generator -I eth1 -r
>
> OpenDataPlane example application.
>
>   Work mode:
> 1.send ipv4 udp packets
>   odp_generator -I eth0 --srcmac fe:0f:97:c9:e0:44  --dstmac
> 32:cb:9b:27:2f:1a --srcip 192.168.0.1 --dstip 192.168.0.2 -m u
> 2.receive ipv4 packets
>   odp_generator -I eth0 -m r
> 3.work likes ping
>   odp_generator -I eth0 --srcmac fe:0f:97:c9:e0:44  --dstmac
> 32:cb:9b:27:2f:1a --srcip 192.168.0.1 --dstip 192.168.0.2 --cpumask
> 0xc -m p
>
> Mandatory OPTIONS:
>   -I, --interface Eth interfaces (comma-separated, no spaces)
>   -a, --srcmac src mac address
>   -b, --dstmac dst mac address
>   -s, --srcip src ip address
>   -d, --dstip dst ip address
>   -m, --mode work mode: send udp(u), receive(r), send icmp(p)
>
> Optional OPTIONS
>   -h, --help   Display help and exit.
>   -e, --srcport src udp port
>   -f, --dstport dst udp port
>   -p, --packetsize payload length of the packets
>   -t, --timeout only for ping mode, wait ICMP reply timeout seconds
>   -i, --interval wait interval ms between sending each packet
>  default is 1000ms. 0 for flood mode
>   -w, --workers specify number of workers need to be assigned to application
>  default is to assign all
>   -n, --count the number of packets to be send
>   -c, --cpumask to set on cores
>   -x, --udp_tx_burst size of UDP TX burst
>   -r, --rx_burst size of RX burst
>   -y, --csum use platform checksum support if available
>  default is disabled
>   -z, --sched use scheduler API to receive packets
>  default is direct mode API
>
> It needs some update.
>
> On 5 June 2018 at 12:00, Maxim Uvarov  wrote:
>> shouldn't it be man page for odp library which we somehow can generate from
>> doxygen?
>>
>> Where do you package odp examples? I think they have to be somewhere under
>> /usr/share/bin/odp-examples and just referenced as example apps. (Like QT
>> examples do). Rather then be "tools".
>>
>>
>> Maxim.
>>
>> On 5 June 2018 at 10:46, Dmitry Eremin-Solenikov <
>> dmitry.ereminsoleni...@linaro.org> wrote:
>>
>>> Hello,
>>>
>>> To finish ODP packaging work I have to provide manpages for ODP tools
>>> that are going to be packages. I've written manpages for odp_hello and
>>> odp_crypto, however
>>> I'm asking for the help in writing manpages for l2fwd/l3fwd/generator.
>>> Could you please help me by sketching clean descriptions of what these
>>> tools do, that I can put into manpage?
>>>
>>> --
>>> With best wishes
>>> Dmitry
>>>


Re: [lng-odp] odp tools manpages

2018-06-05 Thread Bogdan Pricope
Start from 'help' option of odp_generator:

# ./example/generator/odp_generator -h

Usage: odp_generator OPTIONS
  E.g. odp_generator -I eth1 -r

OpenDataPlane example application.

  Work mode:
1.send ipv4 udp packets
  odp_generator -I eth0 --srcmac fe:0f:97:c9:e0:44  --dstmac
32:cb:9b:27:2f:1a --srcip 192.168.0.1 --dstip 192.168.0.2 -m u
2.receive ipv4 packets
  odp_generator -I eth0 -m r
3.work likes ping
  odp_generator -I eth0 --srcmac fe:0f:97:c9:e0:44  --dstmac
32:cb:9b:27:2f:1a --srcip 192.168.0.1 --dstip 192.168.0.2 --cpumask
0xc -m p

Mandatory OPTIONS:
  -I, --interface Eth interfaces (comma-separated, no spaces)
  -a, --srcmac src mac address
  -b, --dstmac dst mac address
  -s, --srcip src ip address
  -d, --dstip dst ip address
  -m, --mode work mode: send udp(u), receive(r), send icmp(p)

Optional OPTIONS
  -h, --help   Display help and exit.
  -e, --srcport src udp port
  -f, --dstport dst udp port
  -p, --packetsize payload length of the packets
  -t, --timeout only for ping mode, wait ICMP reply timeout seconds
  -i, --interval wait interval ms between sending each packet
 default is 1000ms. 0 for flood mode
  -w, --workers specify number of workers need to be assigned to application
 default is to assign all
  -n, --count the number of packets to be send
  -c, --cpumask to set on cores
  -x, --udp_tx_burst size of UDP TX burst
  -r, --rx_burst size of RX burst
  -y, --csum use platform checksum support if available
 default is disabled
  -z, --sched use scheduler API to receive packets
 default is direct mode API

It needs some update.

On 5 June 2018 at 12:00, Maxim Uvarov  wrote:
> shouldn't it be man page for odp library which we somehow can generate from
> doxygen?
>
> Where do you package odp examples? I think they have to be somewhere under
> /usr/share/bin/odp-examples and just referenced as example apps. (Like QT
> examples do). Rather then be "tools".
>
>
> Maxim.
>
> On 5 June 2018 at 10:46, Dmitry Eremin-Solenikov <
> dmitry.ereminsoleni...@linaro.org> wrote:
>
>> Hello,
>>
>> To finish ODP packaging work I have to provide manpages for ODP tools
>> that are going to be packages. I've written manpages for odp_hello and
>> odp_crypto, however
>> I'm asking for the help in writing manpages for l2fwd/l3fwd/generator.
>> Could you please help me by sketching clean descriptions of what these
>> tools do, that I can put into manpage?
>>
>> --
>> With best wishes
>> Dmitry
>>


Re: [lng-odp] ODP packet reference API usecase

2018-02-20 Thread Bogdan Pricope
On 19 February 2018 at 16:32, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> On Mon, Feb 19, 2018 at 7:36 AM, Bogdan Pricope
> <bogdan.pric...@linaro.org> wrote:
>>
>> On 17 February 2018 at 03:36, Bill Fischofer <bill.fischo...@linaro.org> 
>> wrote:
>> > Changed to post this to the ODP mailing list, as this is a good topic to
>> > discuss there.
>> >
>> > Let's first back up a bit and discuss the intent behind packet references.
>> > Packets typically consist of one or more headers followed by a payload.
>> > References are designed to allow multiple unique headers to share a common
>> > payload, which must be treated as read/only. This is because headers
>> > typically have things like unique destination addresses (for multicast) or
>> > IP identifiers (for retransmission). A fundamental assumption of the ODP
>> > programming model is that a packet handle is owned by only one thread at a
>> > time. If two or more threads were to make simultaneous accesses to a packet
>> > through the same handle, the result would be unpredictable race conditions
>> > and likely data corruption.This is why the shared part of any packet
>> > reference must be treated as read only by all parties.
>> >
>> > So any packet reference consists of a R/W prefix, which is unique to that
>> > reference, followed by a (potentially) shared R/O suffix. The point at 
>> > which
>> > the R/O suffix begins is set by the offset parameter. For dynamic 
>> > references
>> > the prefix can either start out null, which is what odp_packet_ref() does,
>> > or can be supplied by the caller, which is what odp_packet_ref_pkt() does.
>> > In both cases the R/W prefix can be modified
>> >
>> > With this background let's look at the specifics.
>> >
>> > On Fri, Feb 16, 2018 at 9:31 AM, Bogdan Pricope <bogdan.pric...@linaro.org>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I am trying to use ODP packet reference API to improve transmission of
>> >> TCP data. Yet, it seems current API is not enough for this.
>> >>
>> >> Usecase:  three data areas stored inside odp_packet_t
>> >>
>> >> mb1: size 40 bytes – to send last 20 bytes
>> >> mb2: size 40 bytes – to send 40 bytes
>> >> mb3: size 40 bytes – to send first 20 bytes
>> >>
>> >
>> > Are you looking at three areas within the same packet or three areas that
>> > are in separate packets? You cannot create a reference to part of a packet.
>> > The only control is the starting offset within the packet that is to become
>> > the shared portion of the reference. That extends to the end of the packet
>> > on which the reference is created. We had considered adding a length
>> > parameter but that would pose undue implementation complications.
>>
>> Each data area is in separate odp packet: this is generated by 3 calls
>> to an API equivalent to:
>>
>> ssize_t send(int sockfd, const void *buf, size_t len, int flags);
>>
>> Buffer 'buf' provided by application is stored as odp_packet_t inside
>> socket send buffer array.
>
>
> You can certainly use odp_packet_offset() to get addressability to a
> particular offset within a packet and send() from there. You just need
> to be aware of potential segmentation along the way (seg_len value
> returned from the odp_packet_offset() call). If you need a particular
> offset/len to be contiguously addressable odp_packet_align() may be
> used to force that, but that can be an expensive operation if the
> packet has to be resegmented to meet the needs expressed by the call.

I meant, send() calls are generating the tree data areas:
 - application calls send()
 - ofp identifies socket structure
 - ofp copy buf in an odp_packet_t and store it in socket's send sockbuf.

Usually, it will try to send packet form sockbuf immediately, but in
congestion situations, it may stay longer in sockbuf.

Eventually, send window is long enough and ofp will try to aggregate
multiple sends into one bigger packet.

Right now, this is done with memcpy(), but I was wondering if we can
use packet ref APIs

>
>>
>>
>> Packetization function receives as arguments: a list of payload
>> buffers (odp_packet_t), offset (start of the un-ack data) and
>> a len (min(data available, send window size)). Length parameter is needed.
>
>
> The odp_pktout_send() API currently does not support sending partial
> packets, however you can simulate this with references. If you've
> ACK'd a b

Re: [lng-odp] ODP packet reference API usecase

2018-02-19 Thread Bogdan Pricope
On 17 February 2018 at 03:36, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> Changed to post this to the ODP mailing list, as this is a good topic to
> discuss there.
>
> Let's first back up a bit and discuss the intent behind packet references.
> Packets typically consist of one or more headers followed by a payload.
> References are designed to allow multiple unique headers to share a common
> payload, which must be treated as read/only. This is because headers
> typically have things like unique destination addresses (for multicast) or
> IP identifiers (for retransmission). A fundamental assumption of the ODP
> programming model is that a packet handle is owned by only one thread at a
> time. If two or more threads were to make simultaneous accesses to a packet
> through the same handle, the result would be unpredictable race conditions
> and likely data corruption.This is why the shared part of any packet
> reference must be treated as read only by all parties.
>
> So any packet reference consists of a R/W prefix, which is unique to that
> reference, followed by a (potentially) shared R/O suffix. The point at which
> the R/O suffix begins is set by the offset parameter. For dynamic references
> the prefix can either start out null, which is what odp_packet_ref() does,
> or can be supplied by the caller, which is what odp_packet_ref_pkt() does.
> In both cases the R/W prefix can be modified
>
> With this background let's look at the specifics.
>
> On Fri, Feb 16, 2018 at 9:31 AM, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>>
>> Hi,
>>
>> I am trying to use ODP packet reference API to improve transmission of
>> TCP data. Yet, it seems current API is not enough for this.
>>
>> Usecase:  three data areas stored inside odp_packet_t
>>
>> mb1: size 40 bytes – to send last 20 bytes
>> mb2: size 40 bytes – to send 40 bytes
>> mb3: size 40 bytes – to send first 20 bytes
>>
>
> Are you looking at three areas within the same packet or three areas that
> are in separate packets? You cannot create a reference to part of a packet.
> The only control is the starting offset within the packet that is to become
> the shared portion of the reference. That extends to the end of the packet
> on which the reference is created. We had considered adding a length
> parameter but that would pose undue implementation complications.

Each data area is in separate odp packet: this is generated by 3 calls
to an API equivalent to:

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

Buffer 'buf' provided by application is stored as odp_packet_t inside
socket send buffer array.

Packetization function receives as arguments: a list of payload
buffers (odp_packet_t), offset (start of the un-ack data) and
a len (min(data available, send window size)). Length parameter is needed.

>
>>
>>
>> Resulting packet should look like:
>> mb0: len 32 bytes to hold IPv4 + TCP headers
>> reference to mb1: 20 bytes offset, 20 bytes len
>> reference to mb2: 0 bytes offset, 40 bytes len
>> reference to mb3: 0 offset, 20 bytes len
>
>
> What you're describing here is either a composite packet that is assembled
> from multiple different packets via odp_packet_concat(), or a compound
> reference where the packet on which you're creating a reference is itself a
> reference. You cannot create a reference directly to more than one packet.

I meant a compound reference.

>
>>
>>
>>
>> API calls:
>> pkt = odp_packet_alloc(pool, 32);
>> pkt = odp_packet_ref_pkt(mb1, 20, pkt);
>> pkt = odp_packet_ref_pkt(mb2, 0, pkt);
>> pkt = odp_packet_ref_pkt(mb3, 0, pkt);
>
>
> Not sure if this is an omission, but having pkt on both sides of the
> assignment here is attempting to create a circular reference (pkt refers to

I thought it works like:

pkt = pkt + new_buff;

> itself) and that is expressly forbidden by the APIs. The proper way to do
> what I think you're trying to do is:
>
> odp_packet_t mb0, mb1, mb2, mb3, refpkt;
>
> ... setup mb0 to hold 14 bytes of Ethernet header
> ... setup mb1 to hold 20 bytes of IPv4 header
> ... setup mb2 to hold 20 bytes of TCP header
> ... setup mb3 to hold your payload
>
> refpkt = odp_packet_ref_pkt(odp_packet_ref_pkt(odp_packet_ref_pkt(mb3, 0,
> mb2), 0, mb1), 0, mb0);
>

It should work (except for missing length part) on single thread
scenario, yet is an odd construction.
Not sure if single thread scenario is good enough for this usecase.


> You of course could use intermediate assignments to capture the handles for
> the intermediate reference.
>
> The result is refpkt is the handle to the composite reference {mb0 || mb1 ||
> mb2 || mb3}, 

Re: [lng-odp] unexpected packet handling behavior with dpdk pktio support

2018-02-06 Thread Bogdan Pricope
Explanation may be related to RSS.

Dpdk pktio is using RSS - traffic is hashed and sent to a specific
queue. You have two RX queues (pktin) that are polled with
odp_pktin_recv(). If you stop polling on one queue (put one of the
threads in busy loop or sleep()), it will not mean that the other will
take entire traffic: I do not know dpdk so well but I suspect that a
number of packets are hold on that pktin and pool is exhausted.

/B

On 6 February 2018 at 14:10, Elo, Matias (Nokia - FI/Espoo)
 wrote:
>
>
>> On 6 Feb 2018, at 13:55, Elo, Matias (Nokia - FI/Espoo) 
>>  wrote:
>>
>>
>>
>>> On 5 Feb 2018, at 19:42, Bill Fischofer  wrote:
>>>
>>> Thanks, Gyanesh, that does sound like a bug. +cc Matias: Can you comment on 
>>> this?
>>>
>>> On Mon, Feb 5, 2018 at 5:09 AM, gyanesh patra  
>>> wrote:
>>> I am testing an l2fwd use-case. I am executing the use-case with two
>>> CPUs & two interfaces.
>>> One interface with 2 Rx queues receives pkts using 2 threads with 2
>>> associated CPUs. Both the
>>> threads can forward the packet over the 2nd interface which also has 2 Tx
>>> queues mapped to
>>> 2 CPUs. I am sending packets from an external packet generator and
>>> confirmed that both
>>> queues are receiving packets.
>>> *When I run odp_pktin_recv() on both the queues, the packet*
>>> * forwarding works fine. But if I put a sleep() or add a busy loop instead
>>> of odp_pktin_recv() *
>>> *on one thread, then the other thread stops receiving packets. If I
>>> replace the sleep with odp_pktin_recv(), both the queues start receiving
>>> packets again. *I encountered this problem on the DPDK pktio support on
>>> ODP 1.16 and ODP 1.17.
>>> On socket-mmap it works fine. Is it expected behavior or a potential bug?
>>>
>>
>>
>> Hi Gyanesh,
>>
>> Could you please share an example code which produces this issue? Does this 
>> happen also if you enable zero-copy dpdk pktio (--enable-dpdk-zero-copy)?
>>
>> Socket-mmap pktio doesn't support MQ, so comparison to that doesn't make 
>> much sense. Netmap pktio supports MQ.
>>
>> Regards,
>> Matias
>>
>
> Using too small packet pool can also cause symptoms like this, so you could 
> try increasing packet pool size.
>
> -Matias
>


Re: [lng-odp] problem about odp-ovs(with dpdk)

2018-01-16 Thread Bogdan Pricope
See below commands (adapt to your PCI IDs and driver):

${DPDK_PATH}/usertools/dpdk-devbind.py -s
${DPDK_PATH}/usertools/dpdk-devbind.py -u :01:00.0
${DPDK_PATH}usertools/dpdk-devbind.py -u :01:00.1
${DPDK_PATH}/usertools/dpdk-devbind.py --bind=igb_uio  :01:00.0
${DPDK_PATH}/usertools/dpdk-devbind.py --bind=igb_uio  :01:00.1

On 16 January 2018 at 14:36, Maxim Uvarov  wrote:
> On 01/16/18 10:35, lin huang wrote:
>> Hi guys,
>>I get a problem when I try to use odp-ovs with odp-dpdk.
>> I compiled the odp-dpdk and odp-ovs successfully. and then I want to try add 
>> a port to ovs bridge with the following command:
>>
>> ovs-vsctl add-port br0 odp:enp0s8 -- set Interface odp:enp0s8 type=odp
>>
>> these commands work properly when I use odp-ovs with odp-linux.
>> But when I input these command when I use odp-ovs with odp-dpdk it failed.
>>
>> The ovs-vswitchd.log content:
>> root@vagrant:/usr/local/bin# tail 
>> /usr/local/var/log/openvswitch/ovs-vswitchd.log
>> 2018-01-16T07:09:51.384Z|00049|bridge|WARN|could not open network device 
>> odp:enp0s8 (Address family not supported by protocol)
>> 2018-01-16T07:10:04.683Z|00050|odp|ERR|../linux-generic/odp_packet_io.c:226:setup_pktio_entry():Unable
>>  to init any I/O type.
>> 2018-01-16T07:10:04.683Z|00051|odp|ERR|Error: odp_pktio_open() failed
>> 2018-01-16T07:10:04.685Z|00052|bridge|WARN|could not open network device 
>> odp:enp0s8 (No such file or directory)
>>
>> So, are there somebody knows how it work?? Or how to configure it???
>> I need you help
>>
>> Thank you very much!!
>>
>
> In dpdk interfaces names are numbers 0, 1, 2. And you need
> dpdk-devbind.py to move nic from linux mode to kernel mode.
> You can find example how to do it from this log:
> https://lng.validation.linaro.org/scheduler/job/23296.1
>
> Best regards,
> Maxim.


Re: [lng-odp] RSS in ODP

2018-01-04 Thread Bogdan Pricope
I guess, the issue is not how to hash traffic in different scheduled
queues but how to lock a scheduled queue to a single thread (core):
sched.sync guarantees that at one moment one queue is scheduled to a
single thread but not on the same thread all the times - this may be
enough for some implementations (to avoid some locks) but not enough
for others.

One problem is that all pktio sched queues are assigned to a single
sched group that is assigned to a single group of threads/cores. If I
understand correctly, Bill suggests classification + sched queues,
where each queue is assigned to a different sched group that is
assigned to a single thread/core.

Other idea is to use direct mode (+ RSS), where each worker is polling
from the its own pktin all the time (odp_pktin_recv()).

On 4 January 2018 at 10:24, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Oriol
>> Arcas
>> Sent: Wednesday, January 03, 2018 7:12 PM
>> To: LNG ODP Mailman List 
>> Subject: [lng-odp] RSS in ODP
>>
>> Hello and happy new year,
>>
>> In our company we are looking into scaling the odp_schedule() calls.
>> Currently we are manually doing Receive Side Scaling, which requires one
>> CPU to receive all the packets and pass them to other worker CPU in a
>> flow-deterministic way (i.e., not spreading the packets from a TCP flow to
>> different CPUs). Obviously this is a bottleneck.
>>
>> It would be great if ODP had optional RSS policies, which ultimately would
>> assign packets from the same flow to a single thread in the schedule group
>> (usually hashing the address tuple). Would this probably mean having
>> dedicated queues?
>>
>> I don't know if there is something similar in ODP already which I have
>> missed. I'll thank any feedback!
>>
>> Best regards,
>>
>> --
>> Oriol Arcas
>> Software Engineer
>> Starflow Networks
>
>
> Our l2fwd test application (odp_l2fwd.c) configures packet input hashing, 
> which is in practice RSS, but could be also some other implementation defined 
> packet input hash function. You can take a look from there. The same hash 
> configuration is possible for both direct pktin queues and scheduled event 
> queues. For scheduled queues you would enable it something like this:
>
> /* Normal interface open and config steps */
> pktio = odp_pktio_open(dev, pool, _param);
> odp_pktio_config(pktio, );
>
> /*
>  * Setup packet input hashing into scheduled event queues
>  */
> if (num_rx_queues > capa.max_input_queues)
> num_rx_queues = capa.max_input_queues;
>
> odp_pktin_queue_param_init(_param);
>
> pktin_param.queue_param.sched.prio  = ODP_SCHED_PRIO_DEFAULT;
> pktin_param.queue_param.sched.sync  = ODP_SCHED_SYNC_ATOMIC;
> pktin_param.queue_param.sched.group = ODP_SCHED_GROUP_ALL;
> pktin_param.hash_enable = 1;
> pktin_param.hash_proto.proto.ipv4_udp = 1;
> pktin_param.num_queues  = num_rx_queues;
>
> if (odp_pktin_queue_config(pktio, _param))
> return -1;
>
> /* Optionally, see which event queues has been created by the previous call.
>  * May e.g. want to set queue contexts here.
>  */
> if (odp_pktin_event_queue(pktio, rx_queues, num_rx_queues) != num_rx_queues)
> return -1;
>
> /* Starts packet input */
> odp_pktio_start(pktio);
>
> /* Use scheduler to receive packets ...*/
>
>


Re: [lng-odp] odp dpdk

2017-12-07 Thread Bogdan Pricope
@Maxim: after PR327 is merged I'll make the changes to replace
scheduler mode with direct pktio mode.

@Honnappa: Right now the sender mode is using one pktout_queue per
thread. Can be modified for more interfaces (more pktout_queue) of
course but I would vote for faster interfaces (40G ?).

@Bill: Nice!!!... but kind of tricky to get it right (in limited
time). The simple workaround is using 40G interfaces for this
benchmark (if I remember correctly from Nokia's results, it goes to
around 20 mpps per core on a regular Xeon)

On 7 December 2017 at 21:32, Bill Fischofer <bill.fischo...@linaro.org> wrote:
>
>
> On Thu, Dec 7, 2017 at 12:55 PM, Honnappa Nagarahalli
> <honnappa.nagaraha...@linaro.org> wrote:
>>
>> On 7 December 2017 at 08:01, Bogdan Pricope <bogdan.pric...@linaro.org>
>> wrote:
>> > TX is at line rate. Probably will get RX at line rate in direct mode,
>> > too.
>> > Problem is how can you see the performance increase/degradation if you
>> > can process more than line rate with one core?
>>
>> Any possibility to add one more port?
>>
>
> The usual way to measure this is to insert a process_packet() routine in the
> loop that consumes a configurable number of cycles. Real applications do
> more than just RX/TX processing but do something with the packets. The lower
> the system overhead the larger the cycle budget process_packet() has while
> maintaining line rate. A good benchmarking tool will self-tune this to find
> the number of cycles process_packet() can consume at line rate. That's the
> measure of efficiency of most interest from a data plane application
> perspective.
>
>>
>> >
>> > I guess .. enable csum option... ?
>> >
>> > On 7 December 2017 at 15:46, Maxim Uvarov <maxim.uva...@linaro.org>
>> > wrote:
>> >> nice. TX is on line rate,  right?  Next step probably to add RX path
>> >> without
>> >> scheduler. And we will have good testing environment.
>> >>
>> >>
>> >> On 7 December 2017 at 16:12, Bogdan Pricope <bogdan.pric...@linaro.org>
>> >> wrote:
>> >>>
>> >>> More results with odp_generator in lava setup:
>> >>>
>> >>>  7.6 mpps  (TX) /  5.9 mpps (RX) - api-next with PR313 (Petri):
>> >>>  8.3 mpps  (TX) /  6.3 mpps (RX) - api-next with PR313 (Petri) +
>> >>> remove 1m sleep + replace atomic counters
>> >>> 14.8 mpps (TX) /  6.5 mpps (RX) - api-next with PR313 (Petri) + remove
>> >>> 1m sleep + replace atomic counters + remove csum
>> >>> calculation/validation
>> >>> 14.8 mpps (TX) /  6.8 mpps (RX) - master with PR327 (remove 1m sleep +
>> >>> replace atomic counters + remove csum calculation/validation)
>> >>>
>> >>> /Bogdan
>> >>>
>> >>>
>> >>> On 6 December 2017 at 13:49, Maxim Uvarov <maxim.uva...@linaro.org>
>> >>> wrote:
>> >>> > small update. Double checked that increasing num of desc does not
>> >>> > give
>> >>> > any
>> >>> > effect in odp_generator.
>> >>> >
>> >>> > Disable check sums in odp_generator increases TX from 7M to 13M pps
>> >>> > and
>> >>> > RX
>> >>> > from 5.9M to 6.1M pps.
>> >>> > Because of generator uses predefined packets with calculated
>> >>> > checksum -
>> >>> > there is no need to enable checksum inside generator.
>> >>> >
>> >>> > It looks like problem inside DPDK driver itself.
>> >>> >
>> >>> > For this PR I think we need to merge it together with changes to
>> >>> > odp_generator (the same as for l2fwd) to enable hw check sum,
>> >>> > which has to be disabled by default.
>> >>> >
>> >>> > Maxim.
>> >>> >
>> >>> >
>> >>> > On 6 December 2017 at 10:46, Maxim Uvarov <maxim.uva...@linaro.org>
>> >>> > wrote:
>> >>> >>
>> >>> >> skip this message. I will recheck. Pushed to lava wrong branch.
>> >>> >>
>> >>> >> On 6 December 2017 at 10:42, Maxim Uvarov <maxim.uva...@linaro.org>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Ilias was right yesterday. If number of descriptors increased to
>> >>> >>> 1024

Re: [lng-odp] odp dpdk

2017-12-07 Thread Bogdan Pricope
TX is at line rate. Probably will get RX at line rate in direct mode, too.
Problem is how can you see the performance increase/degradation if you
can process more than line rate with one core?

I guess .. enable csum option... ?

On 7 December 2017 at 15:46, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> nice. TX is on line rate,  right?  Next step probably to add RX path without
> scheduler. And we will have good testing environment.
>
>
> On 7 December 2017 at 16:12, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>>
>> More results with odp_generator in lava setup:
>>
>>  7.6 mpps  (TX) /  5.9 mpps (RX) - api-next with PR313 (Petri):
>>  8.3 mpps  (TX) /  6.3 mpps (RX) - api-next with PR313 (Petri) +
>> remove 1m sleep + replace atomic counters
>> 14.8 mpps (TX) /  6.5 mpps (RX) - api-next with PR313 (Petri) + remove
>> 1m sleep + replace atomic counters + remove csum
>> calculation/validation
>> 14.8 mpps (TX) /  6.8 mpps (RX) - master with PR327 (remove 1m sleep +
>> replace atomic counters + remove csum calculation/validation)
>>
>> /Bogdan
>>
>>
>> On 6 December 2017 at 13:49, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>> > small update. Double checked that increasing num of desc does not give
>> > any
>> > effect in odp_generator.
>> >
>> > Disable check sums in odp_generator increases TX from 7M to 13M pps and
>> > RX
>> > from 5.9M to 6.1M pps.
>> > Because of generator uses predefined packets with calculated checksum -
>> > there is no need to enable checksum inside generator.
>> >
>> > It looks like problem inside DPDK driver itself.
>> >
>> > For this PR I think we need to merge it together with changes to
>> > odp_generator (the same as for l2fwd) to enable hw check sum,
>> > which has to be disabled by default.
>> >
>> > Maxim.
>> >
>> >
>> > On 6 December 2017 at 10:46, Maxim Uvarov <maxim.uva...@linaro.org>
>> > wrote:
>> >>
>> >> skip this message. I will recheck. Pushed to lava wrong branch.
>> >>
>> >> On 6 December 2017 at 10:42, Maxim Uvarov <maxim.uva...@linaro.org>
>> >> wrote:
>> >>>
>> >>> Ilias was right yesterday. If number of descriptors increased to 1024
>> >>> then TX became again 10M.
>> >>>
>> >>> +   ret = rte_eth_tx_queue_setup(port_id, i,
>> >>> +
>> >>> dev_info.tx_desc_lim.nb_max
>> >>> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
>> >>>
>> >>> rte_eth_dev_socket_id(port_id),
>> >>>  txconf);
>> >>>
>> >>> +   ret = rte_eth_rx_queue_setup(port_id, i,
>> >>> +
>> >>> dev_info.rx_desc_lim.nb_max
>> >>> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
>> >>>
>> >>> rte_eth_dev_socket_id(port_id),
>> >>>  NULL,
>> >>> pkt_dpdk->pkt_pool);
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Maxim.
>> >>>
>> >>> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo)
>> >>> <matias@nokia.com> wrote:
>> >>>>
>> >>>> When I tested enabling HW checksum with Fortville NICs (i40e) the
>> >>>> slower
>> >>>> driver path alone caused ~20% throughput drop on l2fwd test. This was
>> >>>> without actually calculating the checksums, I simply forced the
>> >>>> slower
>> >>>> driver path (no vectorization).
>> >>>>
>> >>>> -Matias
>> >>>>
>> >>>>
>> >>>> > On 5 Dec 2017, at 8:59, Bogdan Pricope <bogdan.pric...@linaro.org>
>> >>>> > wrote:
>> >>>> >
>> >>>> > On RX side is kind-of expected result since it uses scheduler mode.
>> >>>> >
>> >>>> > On TX side there is this drop from 10 mpps to 7.69 mpps that is
>> >>>> > unexpected.
>> >>>> >
>> >>>> > So Petri, when you said:
>> >>>> > "DPDK uses less optimized driver code (on Intel NICs at least) when
>> >>>> > any of the L4 checksum offloads is enabled."
>> >>>>

Re: [lng-odp] odp dpdk

2017-12-07 Thread Bogdan Pricope
More results with odp_generator in lava setup:

 7.6 mpps  (TX) /  5.9 mpps (RX) - api-next with PR313 (Petri):
 8.3 mpps  (TX) /  6.3 mpps (RX) - api-next with PR313 (Petri) +
remove 1m sleep + replace atomic counters
14.8 mpps (TX) /  6.5 mpps (RX) - api-next with PR313 (Petri) + remove
1m sleep + replace atomic counters + remove csum
calculation/validation
14.8 mpps (TX) /  6.8 mpps (RX) - master with PR327 (remove 1m sleep +
replace atomic counters + remove csum calculation/validation)

/Bogdan


On 6 December 2017 at 13:49, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> small update. Double checked that increasing num of desc does not give any
> effect in odp_generator.
>
> Disable check sums in odp_generator increases TX from 7M to 13M pps and RX
> from 5.9M to 6.1M pps.
> Because of generator uses predefined packets with calculated checksum -
> there is no need to enable checksum inside generator.
>
> It looks like problem inside DPDK driver itself.
>
> For this PR I think we need to merge it together with changes to
> odp_generator (the same as for l2fwd) to enable hw check sum,
> which has to be disabled by default.
>
> Maxim.
>
>
> On 6 December 2017 at 10:46, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>
>> skip this message. I will recheck. Pushed to lava wrong branch.
>>
>> On 6 December 2017 at 10:42, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>>
>>> Ilias was right yesterday. If number of descriptors increased to 1024
>>> then TX became again 10M.
>>>
>>> +   ret = rte_eth_tx_queue_setup(port_id, i,
>>> +dev_info.tx_desc_lim.nb_max
>>> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
>>>
>>> rte_eth_dev_socket_id(port_id),
>>>  txconf);
>>>
>>> +   ret = rte_eth_rx_queue_setup(port_id, i,
>>> +dev_info.rx_desc_lim.nb_max
>>> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
>>>
>>> rte_eth_dev_socket_id(port_id),
>>>  NULL, pkt_dpdk->pkt_pool);
>>>
>>>
>>>
>>>
>>> Maxim.
>>>
>>> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo)
>>> <matias@nokia.com> wrote:
>>>>
>>>> When I tested enabling HW checksum with Fortville NICs (i40e) the slower
>>>> driver path alone caused ~20% throughput drop on l2fwd test. This was
>>>> without actually calculating the checksums, I simply forced the slower
>>>> driver path (no vectorization).
>>>>
>>>> -Matias
>>>>
>>>>
>>>> > On 5 Dec 2017, at 8:59, Bogdan Pricope <bogdan.pric...@linaro.org>
>>>> > wrote:
>>>> >
>>>> > On RX side is kind-of expected result since it uses scheduler mode.
>>>> >
>>>> > On TX side there is this drop from 10 mpps to 7.69 mpps that is
>>>> > unexpected.
>>>> >
>>>> > So Petri, when you said:
>>>> > "DPDK uses less optimized driver code (on Intel NICs at least) when
>>>> > any of the L4 checksum offloads is enabled."
>>>> >
>>>> > you were referring to this kind of drop in performance?
>>>> >
>>>> > There is that 'folklore' that SW csum is faster on small packets while
>>>> > HW csum is faster on bigger packets. Do you have this kind of data?
>>>> >
>>>> > Anyway, for this particular case (odp_generator), since UDP
>>>> > header/payload is not changing during the test (for now), csum is
>>>> > calculated only once at the beginning of the test: so we are comparing
>>>> > HW IPv4 + HW UDP csum vs. SW IPv4 csum yet, the differences in
>>>> > performance is huge...
>>>> >
>>>> >
>>>> > On 4 December 2017 at 20:37, Maxim Uvarov <maxim.uva...@linaro.org>
>>>> > wrote:
>>>> >> I added isocpus and mounted huge page TX became more stable at 7.6M.
>>>> >> But
>>>> >> anyway it's better to test performance for this PR because previous
>>>> >> speed was 10M.
>>>> >>
>>>> >> Maxim.
>>>> >>
>>>> >> On 12/04/17 19:42, Honnappa Nagarahalli wrote:
>>>> >>> Can you run with Linux-DPDK in ODP 2.0?
>>>> >>>
>>&

Re: [lng-odp] odp dpdk

2017-12-04 Thread Bogdan Pricope
On RX side is kind-of expected result since it uses scheduler mode.

On TX side there is this drop from 10 mpps to 7.69 mpps that is unexpected.

So Petri, when you said:
"DPDK uses less optimized driver code (on Intel NICs at least) when
any of the L4 checksum offloads is enabled."

you were referring to this kind of drop in performance?

There is that 'folklore' that SW csum is faster on small packets while
HW csum is faster on bigger packets. Do you have this kind of data?

Anyway, for this particular case (odp_generator), since UDP
header/payload is not changing during the test (for now), csum is
calculated only once at the beginning of the test: so we are comparing
HW IPv4 + HW UDP csum vs. SW IPv4 csum yet, the differences in
performance is huge...


On 4 December 2017 at 20:37, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> I added isocpus and mounted huge page TX became more stable at 7.6M. But
> anyway it's better to test performance for this PR because previous
> speed was 10M.
>
> Maxim.
>
> On 12/04/17 19:42, Honnappa Nagarahalli wrote:
>> Can you run with Linux-DPDK in ODP 2.0?
>>
>> On 4 December 2017 at 09:54, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>> after clean patches apply and fix in run scripts I made it run.
>>>
>>> But results is really bad. --enable-dpdk-zero-copy
>>>
>>> TX rate is:
>>> 7673155 pps
>>>
>>> RX rate is:
>>> 5989846 pps
>>>
>>>
>>> Before patch PR 313 TX was 10M pps.
>>>
>>> I re run task and TX is 3.3M pps. All tests are single core. So
>>> something strange happens in lava or this PR.
>>>
>>> Maxim.
>>>
>>>
>>> On 12/04/17 17:03, Bogdan Pricope wrote:
>>>> On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:
>>>>
>>>> ODP_REPO='https://github.com/muvarov/odp'
>>>> ODP_BRANCH='api-next'
>>>>
>>>>
>>>> On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:
>>>>
>>>> ODP_REPO='https://github.com/muvarov/odp'
>>>> ODP_BRANCH='devel/api-next_shsum'
>>>>
>>>>
>>>> or are you referring to other test?
>>>>
>>>>
>>>> On 4 December 2017 at 15:53, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>>>>
>>>>>
>>>>> On 4 December 2017 at 15:11, Bogdan Pricope <bogdan.pric...@linaro.org>
>>>>> wrote:
>>>>>>
>>>>>> You need to put 313 on TX side (not RX).
>>>>>
>>>>>
>>>>>
>>>>> both rx and tx have patches from 313. l2fwd works on recv side. Generator
>>>>> does not work.
>>>>>
>>>>> Maxim.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>>>>>> <petri.savolai...@nokia.com> wrote:
>>>>>>> Is the DPDK version 17.08 ? Other versions might not work properly.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Petri
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>>>>>>> Sent: Monday, December 04, 2017 1:10 PM
>>>>>>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
>>>>>>> Cc: Bogdan Pricope <bogdan.pric...@linaro.org>; lng-odp-forward
>>>>>>> <lng-odp@lists.linaro.org>
>>>>>>>
>>>>>>>
>>>>>>> Subject: Re: [lng-odp] odp dpdk
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 313 does not work also:
>>>>>>>
>>>>>>> https://lng.validation.linaro.org/scheduler/job/23242.1
>>>>>>>
>>>>>>> I will replace RX side to l2fwd and see that will be there.
>>>>>>>
>>>>>>> Maxim.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>>>>>>> <petri.savolai...@nokia.com> wrote:
>>>>>>>
>>>>>>> Maxim, try https://github.com/Linaro/odp/

Re: [lng-odp] odp dpdk

2017-12-04 Thread Bogdan Pricope
On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:

ODP_REPO='https://github.com/muvarov/odp'
ODP_BRANCH='api-next'


On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:

ODP_REPO='https://github.com/muvarov/odp'
ODP_BRANCH='devel/api-next_shsum'


or are you referring to other test?


On 4 December 2017 at 15:53, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>
>
> On 4 December 2017 at 15:11, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>>
>> You need to put 313 on TX side (not RX).
>
>
>
> both rx and tx have patches from 313. l2fwd works on recv side. Generator
> does not work.
>
> Maxim.
>
>
>>
>>
>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia.com> wrote:
>> > Is the DPDK version 17.08 ? Other versions might not work properly.
>> >
>> >
>> >
>> > -Petri
>> >
>> >
>> >
>> > From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>> > Sent: Monday, December 04, 2017 1:10 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
>> > Cc: Bogdan Pricope <bogdan.pric...@linaro.org>; lng-odp-forward
>> > <lng-odp@lists.linaro.org>
>> >
>> >
>> > Subject: Re: [lng-odp] odp dpdk
>> >
>> >
>> >
>> > 313 does not work also:
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23242.1
>> >
>> > I will replace RX side to l2fwd and see that will be there.
>> >
>> > Maxim.
>> >
>> >
>> >
>> >
>> >
>> > On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>> > <petri.savolai...@nokia.com> wrote:
>> >
>> > Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
>> > fix
>> > checksum insert for 10/40GE Intel NICs.
>> >
>> > -Petri
>> >
>> >
>> >> -Original Message-
>> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> >> Bogdan Pricope
>> >> Sent: Monday, December 04, 2017 12:21 PM
>> >> To: Maxim Uvarov <maxim.uva...@linaro.org>
>> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> >> Subject: Re: [lng-odp] odp dpdk
>> >>
>> >> I suspect this is actually caused by csum issue in TX side: on RX,
>> >> socket pktio does not validate csum (and accept the packets) but on
>> >> dpdk pktio the csum is validated and packets are dropped.
>> >>
>> >> I am not seeing this in my setup because default txq_flags for igb
>> >> driver (1G interface) is
>> >>
>> >> .txq_flags = 0
>> >>
>> >> while for ixgbe (10G interface) is:
>> >>
>> >> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> >> ETH_TXQ_FLAGS_NOOFFLOADS,
>> >>
>> >>
>> >> /B
>> >>
>> >>
>> >>
>> >>
>> >> On 1 December 2017 at 23:47, Maxim Uvarov <maxim.uva...@linaro.org>
>> >> wrote:
>> >> >
>> >> > Looking to dpdk pktio support and generator. It looks like receive
>> >> > part
>> >> > is broken. If for receive I use sockets it works well but receive
>> >> > with
>> >> > dpdk does not get any packets. For both master and api-next. Can
>> >> > somebody confirm please that it's so. Lava is not supper friendly to
>> >> > debug issue.
>> >> >
>> >> >
>> >> > 1. Recv
>> >> > odp_generator -I 0 -m r -c 0x4
>> >> >
>> >> > https://lng.validation.linaro.org/scheduler/job/23206.1
>> >> > Network devices using DPDK-compatible driver
>> >> > 
>> >> > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> >> > drv=igb_uio unused=
>> >> >
>> >> >
>> >> >
>> >> > 2. Send
>> >> > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
>> >> > 38:ea:a7:93:83:a0
>> >> > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> >> > 5000 -f 5001 -n 8
>> >> >
>> >> > https://lng.validation.linaro.org/scheduler/job/23206.0
>> >> >
>> >> > Thank you,
>> >> > Maxim.
>> >
>> >
>
>


Re: [lng-odp] odp dpdk

2017-12-04 Thread Bogdan Pricope
You need to put 313 on TX side (not RX).

On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
> Is the DPDK version 17.08 ? Other versions might not work properly.
>
>
>
> -Petri
>
>
>
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Monday, December 04, 2017 1:10 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
> Cc: Bogdan Pricope <bogdan.pric...@linaro.org>; lng-odp-forward
> <lng-odp@lists.linaro.org>
>
>
> Subject: Re: [lng-odp] odp dpdk
>
>
>
> 313 does not work also:
>
> https://lng.validation.linaro.org/scheduler/job/23242.1
>
> I will replace RX side to l2fwd and see that will be there.
>
> Maxim.
>
>
>
>
>
> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia.com> wrote:
>
> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to fix
> checksum insert for 10/40GE Intel NICs.
>
> -Petri
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Bogdan Pricope
>> Sent: Monday, December 04, 2017 12:21 PM
>> To: Maxim Uvarov <maxim.uva...@linaro.org>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] odp dpdk
>>
>> I suspect this is actually caused by csum issue in TX side: on RX,
>> socket pktio does not validate csum (and accept the packets) but on
>> dpdk pktio the csum is validated and packets are dropped.
>>
>> I am not seeing this in my setup because default txq_flags for igb
>> driver (1G interface) is
>>
>> .txq_flags = 0
>>
>> while for ixgbe (10G interface) is:
>>
>> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> ETH_TXQ_FLAGS_NOOFFLOADS,
>>
>>
>> /B
>>
>>
>>
>>
>> On 1 December 2017 at 23:47, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>> >
>> > Looking to dpdk pktio support and generator. It looks like receive part
>> > is broken. If for receive I use sockets it works well but receive with
>> > dpdk does not get any packets. For both master and api-next. Can
>> > somebody confirm please that it's so. Lava is not supper friendly to
>> > debug issue.
>> >
>> >
>> > 1. Recv
>> > odp_generator -I 0 -m r -c 0x4
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23206.1
>> > Network devices using DPDK-compatible driver
>> > 
>> > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> > drv=igb_uio unused=
>> >
>> >
>> >
>> > 2. Send
>> > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac 38:ea:a7:93:83:a0
>> > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> > 5000 -f 5001 -n 8
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23206.0
>> >
>> > Thank you,
>> > Maxim.
>
>


Re: [lng-odp] odp dpdk

2017-12-04 Thread Bogdan Pricope
I suspect this is actually caused by csum issue in TX side: on RX,
socket pktio does not validate csum (and accept the packets) but on
dpdk pktio the csum is validated and packets are dropped.

I am not seeing this in my setup because default txq_flags for igb
driver (1G interface) is

.txq_flags = 0

while for ixgbe (10G interface) is:

.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,


/B




On 1 December 2017 at 23:47, Maxim Uvarov  wrote:
>
> Looking to dpdk pktio support and generator. It looks like receive part
> is broken. If for receive I use sockets it works well but receive with
> dpdk does not get any packets. For both master and api-next. Can
> somebody confirm please that it's so. Lava is not supper friendly to
> debug issue.
>
>
> 1. Recv
> odp_generator -I 0 -m r -c 0x4
>
> https://lng.validation.linaro.org/scheduler/job/23206.1
> Network devices using DPDK-compatible driver
> 
> :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=igb_uio unused=
>
>
>
> 2. Send
> odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac 38:ea:a7:93:83:a0
> --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
> 5000 -f 5001 -n 8
>
> https://lng.validation.linaro.org/scheduler/job/23206.0
>
> Thank you,
> Maxim.


Re: [lng-odp] [Linaro/odp] [PATCH API-NEXT v1] api: pktio: clarify odp_pktio_config() restrictions (#247)

2017-10-24 Thread Bogdan Pricope
My opinion is that "undefined behavior" makes sense on the fast
processing path (to limit checks, etc.) and makes no sense on slow
path, especially on configuration API.

On 24 October 2017 at 11:17, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
> From: Bill Fischofer [mailto:notificati...@github.com]
> Sent: Monday, October 23, 2017 5:55 PM
> To: Linaro/odp 
> Cc: Savolainen, Petri (Nokia - FI/Espoo) ; 
> Mention 
> Subject: Re: [Linaro/odp] [PATCH API-NEXT v1] api: pktio: clarify 
> odp_pktio_config() restrictions (#247)
>
> On Mon, Oct 23, 2017 at 8:00 AM, muvarov  wrote:
>
>> From: "Savolainen, Petri (Nokia - FI/Espoo)"
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> > Github ODP bot
>> > Sent: Friday, October 20, 2017 5:00 PM
>> > To: lng-odp@lists.linaro.org
>> > Subject: [lng-odp] [PATCH API-NEXT v1 1/1] api: pktio: clarify
>> > odp_pktio_config() restrictions
>> >
>> > From: Bill Fischofer
>> >
>> > Add clarification that odp_pktio_config() cannot be used to
>> > configure options that are not supported, as indicated by
>> > odp_pktio_capability().
>> >
>> > Signed-off-by: Bill Fischofer
>> > ---
>> > /** Email created from pull request 247 (Bill-Fischofer-Linaro:pktio-
>> > config-doc)
>> > ** https://github.com/Linaro/odp/pull/247
>> > ** Patch: https://github.com/Linaro/odp/pull/247.patch
>> > ** Base sha: e3108af2f0b58c2ceca422b418439bba5de04b11
>> > ** Merge commit sha: fc118350c5aa950e860cd53a6104b0571aa2e59b
>> > **/
>> > include/odp/api/spec/packet_io.h | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/include/odp/api/spec/packet_io.h
>> > b/include/odp/api/spec/packet_io.h
>> > index 52af646a6..48dd76f28 100644
>> > --- a/include/odp/api/spec/packet_io.h
>> > +++ b/include/odp/api/spec/packet_io.h
>> > @@ -605,7 +605,8 @@ unsigned odp_pktio_max_index(void);
>> > * interface setup sequence. Use odp_pktio_capability() to query
>> > configuration
>> > * capabilities. Use odp_pktio_config_init() to initialize
>> > * configuration options into their default values. Default values are
>> > used
>> > - * when 'config' pointer is NULL.
>> > + * when 'config' pointer is NULL. Attempting to configure options that
>> > are
>> > + * not supported, as indicated by odp_pktio_capability(), will be
>> > rejected.
>>
>> Why not leave this as undefined behavior (as is usual for spec violations)? 
>> This addition would say that it's OK to violate the capability spec, since 
>> params are checked anyway (e.g. not use capability but iterate through param 
>> values until success).
>>
>> So are you saying the text should be left as is or that you'd prefer the
> clarification say explicitly that behavior is undefined in this case?
>
> It can be left as is, since we should not repeat on every call that "breaking 
> this spec results undefined behavior". That statement (or entire chapter) 
> could be added to beginning of user guide/ API main page 
> (odp/doc/application-api-guide/output/html/index.html).
>
>
> Something like:
> API specification principles
> 
> Both application and implementation must comply with the API specification. 
> If not otherwise documented, results are undefined if application acts 
> against the specification. For example, if an application passes bad 
> parameters to a function one implementation may report an error, while 
> another would not check those (to maximize performance) but would just crash 
> while using the bad values...
>
>
> So, we'd document those rare cases when API spec guarantees that it's OK to 
> pass bad parameters. By default, it would not be OK and thus application 
> should check capabilities and limit it's requests based on those.
>
>
> -Petri
>
>


Re: [lng-odp] Packet checksum override behavior

2017-10-20 Thread Bogdan Pricope
Hi,

odp_pktio_config() works as you said:

https://github.com/Linaro/odp/blob/api-next/platform/linux-generic/odp_packet_io.c


int odp_pktio_config(odp_pktio_t hdl, const odp_pktio_config_t *config)
{


/* Check config for invalid values */
if (config->pktin.all_bits & ~capa.config.pktin.all_bits) {
ODP_ERR("Unsupported input configuration option\n");
return -1;
}
if (config->pktout.all_bits & ~capa.config.pktout.all_bits) {
ODP_ERR("Unsupported output configuration option\n");
return -1;
}
.
}

/Bogdan

On 20 October 2017 at 03:54, Bill Fischofer <bill.fischo...@linaro.org> wrote:
>
>
> On Thu, Oct 19, 2017 at 8:00 AM, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>>
>> Hi Petri and Janne,
>>
>> On APIs:
>>
>> void odp_packet_l3_chksum_insert(odp_packet_t pkt, int l3);
>> void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4);
>>
>> What is the expected behavior is checksum is requested but interface
>> does not support it?
>>
>> a) best effort - do if you can (do nothing)
>> b) drop packet
>> c) ??
>
>
> The spec is pretty clear on this point:
>
>  * Calling this function is always allowed but the checksum will not be
>  * inserted if the packet is output through a pktio that does not have
>  * the relevant pktout chksum bit set in the pktio capability.
>
> If the pktio doesn't have checksumming capability (as reported by
> odp_pktio_capability()) then these bits will not be set. The real ambiguity
> in the spec is what happens if odp_pktio_capability() reports they are not
> available but odp_pktio_config() attempts to set them. They should either be
> ignored in that case or else the odp_pktio_config() should fail. The latter
> makes more sense since presumably if the application tried to set other
> config options that weren't supported (e.g., loopback mode) that certainly
> should not be silently ignored if it is not supported.
>
>>
>>
>> /Bogdan
>
>


[lng-odp] Packet checksum override behavior

2017-10-19 Thread Bogdan Pricope
Hi Petri and Janne,

On APIs:

void odp_packet_l3_chksum_insert(odp_packet_t pkt, int l3);
void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4);

What is the expected behavior is checksum is requested but interface
does not support it?

a) best effort - do if you can (do nothing)
b) drop packet
c) ??

/Bogdan


Re: [lng-odp] DPDK pktio tests failure

2017-10-04 Thread Bogdan Pricope
... or dpdk tests are really failing...


# ./test/linux-generic/validation/api/pktio/pktio_run_dpdk.sh
running with pktio_main:
pktio: setting up test interfaces pktiop0p1, pktiop1p0, pktiop2p3, pktiop3p2.
HW time counter freq: 3092977409 hz

 PKTIO: initialized loop interface.
 PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to disable.
 PKTIO: initialized pcap interface.
 PKTIO: initialized ipc interface.
 PKTIO: initialized socket mmap, use export
ODP_PKTIO_DISABLE_SOCKET_MMAP=1 to disable.
 PKTIO: initialized socket mmsg,use export
ODP_PKTIO_DISABLE_SOCKET_MMSG=1 to disable.
ODP API version: 1.15.0
ODP implementation name:"odp-linux"
ODP implementation version: "odp-linux" 1.15.0-0 (v1.15.0) 1.15.0.0


 CUnit - A unit testing framework for C - Version 2.1-2
 http://cunit.sourceforge.net/

Using paired interfaces: 0 1
EAL: Detected 4 lcore(s)
PMD: Initializing pmd_pcap for eth_pcap0
PMD: Creating pcap-backed ethdev on numa socket 0
PMD: Initializing pmd_pcap for eth_pcap1
PMD: Creating pcap-backed ethdev on numa socket 0

Suite: Packet I/O Unsegmented
  Test: pktio_test_open ...pktio/dpdk.c:1163:dpdk_open():Invalid dpdk
netdev: nothere
pktio/socket.c:119:mac_addr_get_fd():ioctl(SIOCGIFHWADDR): No such
device: "nothere".
pktio/socket.c:511:sock_setup_pkt():ioctl(SIOCGIFINDEX): No such
device: "nothere".
odp_packet_io.c:229:setup_pktio_entry():Unable to init any I/O type.
passed
  Test: pktio_test_lookup ...passed
  Test: pktio_test_index ...passed
  Test: pktio_test_print ...
pktio
  handle1
  name  0
  type  dpdk
  state opened
  mac   00:00:00:01:02:03
  mtu   8064
  promisc   no
  max input queues  1
  max output queues 1


pktio
  handle1
  name  1
  type  dpdk
  state opened
  mac   00:00:00:01:02:03
  mtu   8064
  promisc   no
  max input queues  1
  max output queues 1

passed
  Test: pktio_test_pktio_config ...passed
  Test: pktio_test_info ...pktio 0
  name   0
  driver dpdk
pktio 1
  name   1
  driver dpdk
passed
  Test: pktio_test_pktin_queue_config_direct ...passed
  Test: pktio_test_pktin_queue_config_sched ...passed
  Test: pktio_test_pktin_queue_config_queue ...passed
  Test: pktio_test_pktout_queue_config ...passed
  Test: pktio_test_plain_queue ...error: header magic invalid 8650752
error: header magic invalid 393473
error: header magic invalid 0
error: header magic invalid 0
error: header magic invalid 393473
FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_plain_multi ...error: header magic invalid 0
error: header magic invalid 393473
FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_sched_queue ...error: header magic invalid 393473
error: header magic invalid 393473
FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_sched_multi ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_recv ...FAILED
1. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_recv_multi ...error: header magic invalid 393473
FAILED
1. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_recv_queue ...FAILED
1. pktio.c:890  - num_rx == TX_BATCH_LEN
  Test: pktio_test_recv_tmo ...passed
  Test: pktio_test_recv_mq_tmo ...passed
  Test: pktio_test_recv_mtu ...error: header magic invalid 0
error: header magic invalid 0
error: header magic invalid 0
error: header magic invalid 0
FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_mtu ... 8064 passed
  Test: pktio_test_promisc ...passed
  Test: pktio_test_mac ...testing mac for 0
 0:0:0:1:2:3 passed
  Test: pktio_test_start_stop ...passed
  Test: pktio_test_recv_on_wonly ...passed
  Test: pktio_test_send_on_ronly ...passed
  Test: pktio_test_plain_multi_event ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_sched_multi_event ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_recv_multi_event ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_statistics_counters ...passed
  Test: pktio_test_pktin_ts ...FAILED
1. pktio.c:2017  - num_rx == TX_BATCH_LENUsing paired interfaces: 0 1

Suite: Packet I/O Segmented
  Test: pktio_test_plain_queue ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_plain_multi ...FAILED
1. pktio.c:661  - num_rx == num_pkts
2. pktio.c:661  - num_rx == num_pkts
  Test: pktio_test_sched_queue ...error: header magic invalid 0
error: header magic invalid 0
FAILED
1. pktio.c:661  - num_rx == 

Re: [lng-odp] generic core + HW specific drivers

2017-10-04 Thread Bogdan Pricope
There are (at least) three cases:

1.   Discovery is done by odp

2.   Discovery is done by application

3.   Discovery is done by a third party entity



For cloud, I would expect a cloud administrator entity will know
exactly the configuration of each ‘target’ and this can be provided to
‘target’ as an environment variable or a file.


This information can be used to:

1.   Generate an odp.conf file (with a predefine structure),
identifying the module(s) to load.


e.g.

module:

{

   modules = ("libodp_thunderx.so.0");

};



2.   Download the actual module libs (e.g. from a network drive)
if cannot be deployed with the application (at the same time)



Ultimately, odp.conf stored in a predetermined location or indicated
as an environment variable will be used by odp-core library to load
the module(s).



ODP_SYSCONFIG_FILE=/tmp/odp.conf ./example/generator/odp_generator -I
1 -m r -c 0x8



/Bogdan

On 4 October 2017 at 15:54, Bill Fischofer  wrote:
> On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Andriy Berestovskyy [mailto:andriy.berestovs...@caviumnetworks.com
>> ]
>> > Sent: Tuesday, October 03, 2017 8:22 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) ;
>> Ola
>> > Liljedahl ; lng-odp@lists.linaro.org
>> > Subject: Re: [lng-odp] generic core + HW specific drivers
>> >
>> > Hey,
>> > Please see below.
>> >
>> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > > So, we should be able to deliver ODP as a set of HW independent and
>> > > HW specific packages (libraries). For example, minimal install would
>> > >  include only odp, odp-linux and odp-test-suite, but when on arm64
>> > > (and especially when on ThunderX) odp-thunderx would be installed
>> >
>> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> > there are no specific platform dependencies (i.e. Cavium ThunderX,
>> > Cavium Octeon, NXP etc).
>> >
>> > In other words, there is no such mechanism in packaging to create a
>> > package odp, which will automatically install package odp-thunderx only
>> > on Cavium ThunderX platforms.
>>
>> I'd expect that ODP main package (e.g. for arm64) would run a script
>> (written by us) during install which digs out information about the system
>> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
>> package would added to search paths when installing into a ThunderX system.
>> If system is not recognized,  ODP libs/header paths would point into
>> odp-linux.
>>
>>
> That's still trying to make this a static configuration that can be done at
> install time. What about VMs/containers that are instantiated on different
> hosts as they are deployed? This really needs to be determined at run time,
> not install time.
>
>
>>
>> >
>> >
>> > > Package:
>> > > * odp * depends on: odp-linux
>> > > * odp-linux * depends on: odp
>> >  > * odp-thunderx [arm64] * depends on: odp
>> >
>> > So installing odp-thunderx we will end up with odp, odp-linux and
>> > odp-thunderx, so still we have switch runtime between odp-linux and
>> > odp-thunderx...
>>
>> I hope it's a matter of probing and installing paths on install time,
>> instead of runtime. It's hard to believe that ODP would be the first
>> package ever to choose and install a library from a set of alternative
>> libraries.
>>
>
> ODP is a pioneer in the sense that it's offering access to platform
> acceleration capabilities, not simple attached device variants. So we may
> well be first in this sense.
>
>
>>
>> >
>> >
>> > All other projects you are mentioning (kernel, DPDK, Xorg) use
>> > architecture dependency (different packages for different architectures)
>> > combined with run time configuration/probing. A kernel driver might be
>> > installed, but it will be unused until configured/probed.
>>
>> Those projects aim to maximize code re-use of the core part and minimize
>> size of the driver part. Optimally, we'd do the opposite - minimize the
>> core part to zero and dynamically link application directly to the right
>> "driver" (== HW specific odp implementation).
>>
>> If there's no core part, run time probing is not needed - install time
>> probing and lib/header path setup is enough.
>>
>
> You're describing the embedded build case, which is similar to what we have
> today with --enable-abi-compat=no. That's not changing. We're only talking
> about what happens for --enable-abi-compat=yes builds.
>
>
>>
>>
>> >
>> > To support multiple platforms, runtime configuration/probing is
>> > inevitable. The real question is who does this probing: ODP itself or
>> > each application independently. To avoid code duplication, ODP looks
>> > like a better choice...
>>
>> Install time probe/conf would be the best choice. The second best would be
>> a dummy "core ODP" implementation which 

Re: [lng-odp] Supporting ODP_PKTIO_OP_MT_SAFE

2017-09-11 Thread Bogdan Pricope
Hi,

There is the case where a a pktio has less pktins than available
cores. It is a valid case? We want to support it?
For example: 4 pktins and 8 cores... or default (socket) pktio with
one pktin/one pktout?

Best regards,
Bogdan

On 11 September 2017 at 11:33, Maxim Uvarov  wrote:
> On 11 September 2017 at 06:26, Brian Brooks  wrote:
>
>> Honnappa,
>>
>> Could your proposal be simplified to: MT-safe pktio should be
>> deprecated because it is not a common use case. Applications will
>> either use MT-unsafe pktio or the MT-safe scheduler.
>>
>> > 1) Polling method - in which one pkt I/O will be created for each
>> receive worker thread. In this case, support for ODP_PKTIO_OP_MT_SAFE is
>> not required.
>>
>
>
> That is not always a case. One pktio can be used in several working
> threads. For that case safe is needed.
>
> All modes are:
> /**
>  * Packet input mode
>  */
> typedef enum odp_pktin_mode_t {
> /** Direct packet input from the interface */
> ODP_PKTIN_MODE_DIRECT = 0,
> /** Packet input through scheduler and scheduled event queues */
> ODP_PKTIN_MODE_SCHED,
> /** Packet input through plain event queues */
> ODP_PKTIN_MODE_QUEUE,
> /** Application will never receive from this interface */
> ODP_PKTIN_MODE_DISABLED
> } odp_pktin_mode_t;
>
> /**
>  * Packet output mode
>  */
> typedef enum odp_pktout_mode_t {
> /** Direct packet output on the interface */
> ODP_PKTOUT_MODE_DIRECT = 0,
> /** Packet output through event queues */
> ODP_PKTOUT_MODE_QUEUE,
> /** Packet output through traffic manager API */
> ODP_PKTOUT_MODE_TM,
> /** Application will never send to this interface */
> ODP_PKTOUT_MODE_DISABLED
> } odp_pktout_mode_t;
>
>
> For DIRECT, QUEUE and TM implementation can have different optimization
> regrades is the same pktio or in/out queue connected to that pktio used in
> single thread or shared between threads. Application can not provide
> synchronization in that case because locking should be done on low level
> for some short period of time. Locking ODP calls will significantly slow
> down data path functions.
>
> Best regards,
> Maxim.
>
>
>
>
>>
>> Absence of MT-safe does not require 1:1 mapping of thread to pktio. It
>> just means that it is the application's responsibility to ensure
>> exclusive access to a pktio.
>>
>> > for high throughput packet I/Os [..] we do not need to support
>> ODP_PKTIO_OP_MT_SAFE
>> > We could keep the support for ODP_PKTIO_OP_MT_SAFE for other pkt I/Os.
>>
>> This would introduce an undesirable leaky abstraction.
>>
>> BB
>>
>> On Sun, Sep 10, 2017 at 12:40 PM, Bill Fischofer
>>  wrote:
>> > We can discuss this during tomorrow's ARCH call, and probably further
>> > at Connect. MT Safe is the default behavior and it's opposite ("MT
>> > Unsafe") was added as a potential optimization when applications
>> > assure implementations that only a single thread will be polling a
>> > PktIn queue or adding to a Pktout queue.
>> >
>> > Ideally, we'd like to retire all application I/O polling and use the
>> > scheduler exclusively, but that's that's a longer-term goal. For now
>> > we have both.
>> >
>> > On Sun, Sep 10, 2017 at 8:11 AM, Honnappa Nagarahalli
>> >  wrote:
>> >> Hi,
>> >> I think there are 2 ways in which pkt I/O will be used:
>> >>
>> >> 1) Polling method - in which one pkt I/O will be created for each
>> >> receive worker thread. In this case, support for ODP_PKTIO_OP_MT_SAFE
>> >> is not required.
>> >> 2) Event method - the scheduler is used to receive packets. In this
>> >> case the scheduler will provide the exclusive access to a pkt I/O.
>> >> Again in this case support for ODP_PKTIO_OP_MT_SAFE is not required.
>> >>
>> >> I am thinking, for high throughput packet I/Os such as dpdk or ODP
>> >> native drivers (in the future), we do not need to support
>> >> ODP_PKTIO_OP_MT_SAFE. The odp_pktio_open API call can return an error
>> >> if ODP_PKTIO_OP_MT_SAFE is asked for.
>> >>
>> >> We could keep the support for ODP_PKTIO_OP_MT_SAFE for other pkt I/Os.
>> >>
>> >> This will save space in cache for the locks as well as instruction
>> cycles.
>> >>
>> >> Thank you,
>> >> Honnappa
>>


[lng-odp] [CLOUD-DEV, RFCv1] examples: register custom pktio_ops module

2017-08-31 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/ddf_app/odp_ddf_app.c  | 16 +++-
 example/ddf_ifs/Makefile.am|  4 +-
 example/ddf_ifs/ddf_ifs_driver.c   | 88 ++
 frameworks/modular/odp_module.h| 10 +++
 .../include/odp_pktio_ops_subsystem.h  | 10 +++
 5 files changed, 125 insertions(+), 3 deletions(-)

diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c
index af864ee..619663e 100644
--- a/example/ddf_app/odp_ddf_app.c
+++ b/example/ddf_app/odp_ddf_app.c
@@ -20,9 +20,12 @@
 int main(int argc, char *argv[])
 {
odp_instance_t instance;
+   odp_pktio_t pktio = ODP_PKTIO_INVALID;
 
-   (void)argc;
-   (void)argv;
+   if (argc == 1 || argc > 2) {
+   printf("Error: invalid parameter.\nUsage:\n\t%s \n", 
argv[0]);
+   exit(0);
+   }
 
EXAMPLE_DBG("Start DDF Application...\n");
 
@@ -37,6 +40,15 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
 
+   /* Open pktio*/
+   pktio = odp_pktio_open(argv[1], ODP_POOL_INVALID, NULL);
+   if (pktio == ODP_PKTIO_INVALID)
+   EXAMPLE_ERR("Error: Failed to open pktio \"%s\".\n", argv[1]);
+
+   /* Close pktio*/
+   if (odp_pktio_close(pktio))
+   EXAMPLE_ERR("Error: Failed to close pktio \"%s\".\n", argv[1]);
+
/* Print ddf objects*/
odpdrv_print_all();
 
diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am
index aa892ac..8bd666e 100644
--- a/example/ddf_ifs/Makefile.am
+++ b/example/ddf_ifs/Makefile.am
@@ -2,8 +2,10 @@ LIB   = $(top_builddir)/lib
 
 AM_CPPFLAGS +=  -I$(srcdir) \
-I$(top_srcdir)/include \
+   -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@ \
-I$(top_srcdir)/platform/@with_platform@/include \
-   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@
+   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@ \
+   -I$(top_srcdir)/frameworks/modular
 
 lib_LTLIBRARIES = $(LIB)/libddf_ifs.la
 
diff --git a/example/ddf_ifs/ddf_ifs_driver.c b/example/ddf_ifs/ddf_ifs_driver.c
index 53f9475..0a4cc29 100644
--- a/example/ddf_ifs/ddf_ifs_driver.c
+++ b/example/ddf_ifs/ddf_ifs_driver.c
@@ -7,9 +7,19 @@
 #include 
 #include 
 #include "odp_drv.h"
+#include 
 #include "ddf_ifs_api.h"
 #include "ddf_ifs_driver.h"
 
+#define DDF_IFS_NAME_SIZE 50
+#define DDF_IFS_DEV_PREFIX "ddf_ifs:"
+#define DDF_IFS_DEV_PREFIX_LEN 8
+/** Packet socket using netmap mmaped rings for both Rx and Tx */
+typedef struct {
+   char dev_name[DDF_IFS_NAME_SIZE];   /**< interface name */
+} pktio_ops_ddf_ifs_data_t;
+
+
 static odpdrv_driver_t ddf_ifs_driver;
 static int drv_data = 12;
 
@@ -46,8 +56,79 @@ static int ddf_ifs_driver_remove(void)
return 0;
 }
 
+static int ddf_ifs_init_global(void)
+{
+   printf("%s()\n", __func__);
+   return 0;
+}
+static int ddf_ifs_term_global(void)
+{
+   printf("%s()\n", __func__);
+   return 0;
+}
+
+static int ddf_ifs_open(odp_pktio_t pktio ODP_UNUSED, pktio_entry_t 
*pktio_entry,
+   const char *devname, odp_pool_t pool)
+{
+   pktio_ops_ddf_ifs_data_t *pkt_ddf_ifs = _ops_data(pktio_entry, ddf_ifs);
+
+   (void)pktio;
+   (void)pool;
+
+   printf("%s(%s)\n", __func__, devname);
+   if (strncmp(devname, DDF_IFS_DEV_PREFIX, DDF_IFS_DEV_PREFIX_LEN) == 0)
+   devname += DDF_IFS_DEV_PREFIX_LEN;
+   else
+   return -1;
+
+   strcpy(pkt_ddf_ifs->dev_name, devname);
+   printf("%s() - device %s oppened!!!\n", __func__,
+  pkt_ddf_ifs->dev_name);
+   return 0;
+}
+
+static int ddf_ifs_close(pktio_entry_t *pktio_entry)
+{
+   pktio_ops_ddf_ifs_data_t *pkt_ddf_ifs = _ops_data(pktio_entry, ddf_ifs);
+
+   printf("%s() - device %s closed.\n", __func__, pkt_ddf_ifs->dev_name);
+
+   return 0;
+}
+
+static pktio_ops_module_t ddf_ifs_pktio_ops = {
+   .base = {
+   .name = "ddf_ifs",
+   .init_local = NULL,
+   .term_local = NULL,
+   .init_global = ddf_ifs_init_global,
+   .term_global = ddf_ifs_term_global,
+   },
+   .open = ddf_ifs_open,
+   .close = ddf_ifs_close,
+   .start = NULL/*ddf_ifs_start*/,
+   .stop = NULL/*ddf_ifs_stop*/,
+   .stats = NULL/*ddf_ifs_stats*/,
+   .stats_reset = NULL/*ddf_ifs_stats_reset*/,
+   .pktin_ts_res = NULL,
+   .pktin_ts_from_ns = NULL,
+   .recv = NULL/*ddf_ifs_recv*/,
+   .send = NULL/*ddf_ifs_send*/,
+   .mtu_get = NULL/*ddf_ifs_mtu_get*/,
+   .promisc_mode_set = NULL/*ddf_ifs_promisc_mode_set*/,
+   

[lng-odp] [CLOUD-DEV,RFCv1] Register custom pktio

2017-08-31 Thread Bogdan Pricope
To be applied on top of PR139 and '[CLOUD-DEV,RFCv1] Add generic ops_data 
support' patch

Bogdan Pricope (1):
  examples: register custom pktio_ops module

 example/ddf_app/odp_ddf_app.c  | 16 +++-
 example/ddf_ifs/Makefile.am|  4 +-
 example/ddf_ifs/ddf_ifs_driver.c   | 88 ++
 frameworks/modular/odp_module.h| 10 +++
 .../include/odp_pktio_ops_subsystem.h  | 10 +++
 5 files changed, 125 insertions(+), 3 deletions(-)

-- 
2.1.4



[lng-odp] [CLOUD-DEV,RFCv1] Add generic ops_data support

2017-08-29 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 .../linux-generic/include/odp_config_internal.h|   2 +
 .../linux-generic/include/odp_packet_io_internal.h |  25 ++-
 .../linux-generic/include/odp_pktio_ops_socket.h   |  20 ---
 .../include/odp_pktio_ops_subsystem.h  |  25 ---
 platform/linux-generic/odp_packet_io.c |   1 +
 platform/linux-generic/pktio/common.c  |  85 +
 platform/linux-generic/pktio/dpdk.c| 103 +--
 platform/linux-generic/pktio/ipc.c | 190 +++--
 platform/linux-generic/pktio/loopback.c|  27 ++-
 platform/linux-generic/pktio/netmap.c  |  94 +-
 platform/linux-generic/pktio/pcap.c|  20 +--
 platform/linux-generic/pktio/socket.c  | 117 +++--
 platform/linux-generic/pktio/socket_mmap.c |  46 +++--
 platform/linux-generic/pktio/tap.c |  33 ++--
 14 files changed, 415 insertions(+), 373 deletions(-)

diff --git a/platform/linux-generic/include/odp_config_internal.h 
b/platform/linux-generic/include/odp_config_internal.h
index e8d0acb..f037fc6 100644
--- a/platform/linux-generic/include/odp_config_internal.h
+++ b/platform/linux-generic/include/odp_config_internal.h
@@ -34,6 +34,8 @@
  */
 #define ODP_CONFIG_PKTIO_ENTRIES 64
 
+#define ODP_CONFIG_PKTIO_ODPS_DATA_MAX_SIZE 5500
+
 /*
  * Minimum buffer alignment
  *
diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index 7359b58..585f784 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -46,9 +46,11 @@ typedef union pktio_entry_u pktio_entry_t;
  *  requested number of packets were not handled. */
 #define SOCK_ERR_REPORT(e) (e != EAGAIN && e != EWOULDBLOCK && e != EINTR)
 
+#define _ops_data(_p, _mod) ((pktio_ops_ ## _mod ## _data_t *)_p->s.ops_data)
+
 struct pktio_entry {
const pktio_ops_module_t *ops;  /**< Implementation specific methods */
-   pktio_ops_data_t ops_data;  /**< IO operation specific data */
+   uint8_t ops_data[ODP_CONFIG_PKTIO_ODPS_DATA_MAX_SIZE];
/* These two locks together lock the whole pktio device */
odp_ticketlock_t rxl;   /**< RX ticketlock */
odp_ticketlock_t txl;   /**< TX ticketlock */
@@ -151,6 +153,27 @@ int sock_stats_fd(pktio_entry_t *pktio_entry,
  int fd);
 int sock_stats_reset_fd(pktio_entry_t *pktio_entry, int fd);
 
+/**
+ * Read the MTU from a packet socket
+ */
+uint32_t mtu_get_fd(int fd, const char *name);
+
+/**
+ * Enable/Disable promisc mode for a packet socket
+ */
+int promisc_mode_set_fd(int fd, const char *name, int enable);
+
+/**
+ * Return promisc mode of a packet socket
+ */
+int promisc_mode_get_fd(int fd, const char *name);
+
+
+/**
+ * Get ethtool statistics of a packet socket
+ */
+int ethtool_stats_get_fd(int fd, const char *name, odp_pktio_stats_t *stats);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/platform/linux-generic/include/odp_pktio_ops_socket.h 
b/platform/linux-generic/include/odp_pktio_ops_socket.h
index 32c49c0..179741e 100644
--- a/platform/linux-generic/include/odp_pktio_ops_socket.h
+++ b/platform/linux-generic/include/odp_pktio_ops_socket.h
@@ -99,21 +99,6 @@ ethaddrs_equal(unsigned char mac_a[], unsigned char mac_b[])
 int mac_addr_get_fd(int fd, const char *name, unsigned char mac_dst[]);
 
 /**
- * Read the MTU from a packet socket
- */
-uint32_t mtu_get_fd(int fd, const char *name);
-
-/**
- * Enable/Disable promisc mode for a packet socket
- */
-int promisc_mode_set_fd(int fd, const char *name, int enable);
-
-/**
- * Return promisc mode of a packet socket
- */
-int promisc_mode_get_fd(int fd, const char *name);
-
-/**
  * Return link status of a packet socket (up/down)
  */
 int link_status_fd(int fd, const char *name);
@@ -164,9 +149,4 @@ int rss_conf_set_fd(int fd, const char *name,
  */
 void rss_conf_print(const odp_pktin_hash_proto_t *hash_proto);
 
-/**
- * Get ethtool statistics of a packet socket
- */
-int ethtool_stats_get_fd(int fd, const char *name, odp_pktio_stats_t *stats);
-
 #endif
diff --git a/platform/linux-generic/include/odp_pktio_ops_subsystem.h 
b/platform/linux-generic/include/odp_pktio_ops_subsystem.h
index 7a915b8..ff497a2 100644
--- a/platform/linux-generic/include/odp_pktio_ops_subsystem.h
+++ b/platform/linux-generic/include/odp_pktio_ops_subsystem.h
@@ -78,29 +78,4 @@ typedef ODP_MODULE_CLASS(pktio_ops) {
odp_api_proto(pktio_ops, print) print;
 } pktio_ops_module_t;
 
-/* All implementations of this subsystem */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Per implementation private data
- * TODO: refactory each implementation to hide it internally
- */
-typedef union {
-   void *dpdk;
-   pktio_ops_ipc_data_t i

[lng-odp] [CLOUD-DEV,RFCv1] Generic ops_data storage

2017-08-29 Thread Bogdan Pricope
To be applied on top of PR139

Bogdan Pricope (1):
  Add generic ops_data support

 .../linux-generic/include/odp_config_internal.h|   2 +
 .../linux-generic/include/odp_packet_io_internal.h |  25 ++-
 .../linux-generic/include/odp_pktio_ops_socket.h   |  20 ---
 .../include/odp_pktio_ops_subsystem.h  |  25 ---
 platform/linux-generic/odp_packet_io.c |   1 +
 platform/linux-generic/pktio/common.c  |  85 +
 platform/linux-generic/pktio/dpdk.c| 103 +--
 platform/linux-generic/pktio/ipc.c | 190 +++--
 platform/linux-generic/pktio/loopback.c|  27 ++-
 platform/linux-generic/pktio/netmap.c  |  94 +-
 platform/linux-generic/pktio/pcap.c|  20 +--
 platform/linux-generic/pktio/socket.c  | 117 +++--
 platform/linux-generic/pktio/socket_mmap.c |  46 +++--
 platform/linux-generic/pktio/tap.c |  33 ++--
 14 files changed, 415 insertions(+), 373 deletions(-)

-- 
2.1.4



Re: [lng-odp] [PATCH v1 1/1] example: generator : use packet reference API to generate udp and icmp traffic

2017-08-09 Thread Bogdan Pricope
Thank you, Maxim.

BR,
Bogdan

On 9 August 2017 at 10:48, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Ping.
>
> I need this to be 'finalized' before updating dpdk hw checksum support PR.
>
> BR,
> Bogdan
>
> On 8 August 2017 at 14:00, Github ODP bot <odp...@yandex.ru> wrote:
>> From: Bogdan Pricope <bogdan.pric...@linaro.org>
>>
>> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
>> ---
>> /** Email created from pull request 118 (bogdanPricope:pktref_generator_pr)
>>  ** https://github.com/Linaro/odp/pull/118
>>  ** Patch: https://github.com/Linaro/odp/pull/118.patch
>>  ** Base sha: e76b25aa5cafbf96133fcbd83b856090b0e95f33
>>  ** Merge commit sha: a2a1459eb2047f247e54c2e3476a178c29384326
>>  **/
>>  example/generator/odp_generator.c | 165 
>> +++---
>>  1 file changed, 100 insertions(+), 65 deletions(-)
>>
>> diff --git a/example/generator/odp_generator.c 
>> b/example/generator/odp_generator.c
>> index 9336cec1..f3ec43be 100644
>> --- a/example/generator/odp_generator.c
>> +++ b/example/generator/odp_generator.c
>> @@ -136,6 +136,7 @@ static void millisleep(uint32_t ms,
>> uint64_t ticks = odp_timer_ns_to_tick(tp, 100ULL * ms);
>> odp_event_t ev = odp_timeout_to_event(tmo);
>> int rc = odp_timer_set_rel(tim, ticks, );
>> +
>> if (rc != ODP_TIMER_SUCCESS)
>> EXAMPLE_ABORT("odp_timer_set_rel() failed\n");
>> /* Spin waiting for timeout event */
>> @@ -186,12 +187,76 @@ static int scan_ip(char *buf, unsigned int *paddr)
>>  }
>>
>>  /**
>> + * Setup array of reference packets
>> + *
>> + * @param pool Packet pool
>> + * @param pkt_ref_array Packet array
>> + * @param pkt_ref_array_size Packet array size
>> + * @param setup_ref Packet setup function
>> + * @return 0 success, -1 failed
>> +*/
>> +static int setup_pkt_ref_array(odp_pool_t pool,
>> +  odp_packet_t *pkt_ref_array,
>> +  int pkt_ref_array_size,
>> +  odp_packet_t (*setup_ref)(odp_pool_t))
>> +{
>> +   int i;
>> +
>> +   for (i = 0; i < pkt_ref_array_size; i++) {
>> +   pkt_ref_array[i] = (*setup_ref)(pool);
>> +   if (pkt_ref_array[i] == ODP_PACKET_INVALID)
>> +   break;
>> +   }
>> +
>> +   if (i < pkt_ref_array_size) {
>> +   odp_packet_free_multi(pkt_ref_array, i);
>> +   return -1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +/**
>> + * Setup array of packets
>> + *
>> + * @param pkt_ref_array Reference packet array
>> + * @param pkt_array Packet array
>> + * @param pkt_array_size Packet array size
>> + * @param setup_pkt Packet setup function
>> + * @return 0 success, -1 failed
>> +*/
>> +static int setup_pkt_array(odp_packet_t *pkt_ref_array,
>> +  odp_packet_t  *pkt_array,
>> +  int pkt_array_size,
>> +  int (*setup_pkt)(odp_packet_t))
>> +{
>> +   int i;
>> +
>> +   for (i = 0; i < pkt_array_size; i++) {
>> +   if ((*setup_pkt)(pkt_ref_array[i]))
>> +   break;
>> +
>> +   pkt_array[i] = odp_packet_ref_static(pkt_ref_array[i]);
>> +   if (pkt_array[i] == ODP_PACKET_INVALID)
>> +   break;
>> +   }
>> +   if (i < pkt_array_size) {
>> +   if (i)
>> +   odp_packet_free_multi(pkt_array, i - 1);
>> +
>> +   return -1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +/**
>>   * set up an udp packet reference
>>   *
>>   * @param pool Buffer pool to create packet in
>>   *
>> - * @return Handle of created packet
>> + *
>> + * @retval Handle of created packet
>>   * @retval ODP_PACKET_INVALID  Packet could not be created
>> + *
>>   */
>>  static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>>  {
>> @@ -246,37 +311,27 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>>  /**
>>   * set up an udp packet
>>   *
>> - * @param pool Buffer pool to create packet in
>> - * @param pkt_ref Reference UDP packet
>> + * @param pkt Reference UDP packet
>>   *
>> - * @return Handle of created packet
>> - * @retval OD

Re: [lng-odp] [PATCH v1 1/1] example: generator : use packet reference API to generate udp and icmp traffic

2017-08-09 Thread Bogdan Pricope
Ping.

I need this to be 'finalized' before updating dpdk hw checksum support PR.

BR,
Bogdan

On 8 August 2017 at 14:00, Github ODP bot <odp...@yandex.ru> wrote:
> From: Bogdan Pricope <bogdan.pric...@linaro.org>
>
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
> /** Email created from pull request 118 (bogdanPricope:pktref_generator_pr)
>  ** https://github.com/Linaro/odp/pull/118
>  ** Patch: https://github.com/Linaro/odp/pull/118.patch
>  ** Base sha: e76b25aa5cafbf96133fcbd83b856090b0e95f33
>  ** Merge commit sha: a2a1459eb2047f247e54c2e3476a178c29384326
>  **/
>  example/generator/odp_generator.c | 165 
> +++---
>  1 file changed, 100 insertions(+), 65 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 9336cec1..f3ec43be 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -136,6 +136,7 @@ static void millisleep(uint32_t ms,
> uint64_t ticks = odp_timer_ns_to_tick(tp, 100ULL * ms);
> odp_event_t ev = odp_timeout_to_event(tmo);
> int rc = odp_timer_set_rel(tim, ticks, );
> +
> if (rc != ODP_TIMER_SUCCESS)
> EXAMPLE_ABORT("odp_timer_set_rel() failed\n");
> /* Spin waiting for timeout event */
> @@ -186,12 +187,76 @@ static int scan_ip(char *buf, unsigned int *paddr)
>  }
>
>  /**
> + * Setup array of reference packets
> + *
> + * @param pool Packet pool
> + * @param pkt_ref_array Packet array
> + * @param pkt_ref_array_size Packet array size
> + * @param setup_ref Packet setup function
> + * @return 0 success, -1 failed
> +*/
> +static int setup_pkt_ref_array(odp_pool_t pool,
> +  odp_packet_t *pkt_ref_array,
> +  int pkt_ref_array_size,
> +  odp_packet_t (*setup_ref)(odp_pool_t))
> +{
> +   int i;
> +
> +   for (i = 0; i < pkt_ref_array_size; i++) {
> +   pkt_ref_array[i] = (*setup_ref)(pool);
> +   if (pkt_ref_array[i] == ODP_PACKET_INVALID)
> +   break;
> +   }
> +
> +   if (i < pkt_ref_array_size) {
> +   odp_packet_free_multi(pkt_ref_array, i);
> +   return -1;
> +   }
> +   return 0;
> +}
> +
> +/**
> + * Setup array of packets
> + *
> + * @param pkt_ref_array Reference packet array
> + * @param pkt_array Packet array
> + * @param pkt_array_size Packet array size
> + * @param setup_pkt Packet setup function
> + * @return 0 success, -1 failed
> +*/
> +static int setup_pkt_array(odp_packet_t *pkt_ref_array,
> +  odp_packet_t  *pkt_array,
> +  int pkt_array_size,
> +  int (*setup_pkt)(odp_packet_t))
> +{
> +   int i;
> +
> +   for (i = 0; i < pkt_array_size; i++) {
> +   if ((*setup_pkt)(pkt_ref_array[i]))
> +   break;
> +
> +   pkt_array[i] = odp_packet_ref_static(pkt_ref_array[i]);
> +   if (pkt_array[i] == ODP_PACKET_INVALID)
> +   break;
> +   }
> +   if (i < pkt_array_size) {
> +   if (i)
> +   odp_packet_free_multi(pkt_array, i - 1);
> +
> +   return -1;
> +   }
> +   return 0;
> +}
> +
> +/**
>   * set up an udp packet reference
>   *
>   * @param pool Buffer pool to create packet in
>   *
> - * @return Handle of created packet
> + *
> + * @retval Handle of created packet
>   * @retval ODP_PACKET_INVALID  Packet could not be created
> + *
>   */
>  static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>  {
> @@ -246,37 +311,27 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>  /**
>   * set up an udp packet
>   *
> - * @param pool Buffer pool to create packet in
> - * @param pkt_ref Reference UDP packet
> + * @param pkt Reference UDP packet
>   *
> - * @return Handle of created packet
> - * @retval ODP_PACKET_INVALID  Packet could not be created
> + * @return Success/Failed
> + * @retval 0 on success, -1 on fail
>   */
> -static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
> +static int setup_udp_pkt(odp_packet_t pkt)
>  {
> -   odp_packet_t pkt;
> char *buf;
> odph_ipv4hdr_t *ip;
> unsigned short seq;
>
> -   pkt = odp_packet_alloc(pool, args->appl.payload + ODPH_UDPHDR_LEN +
> -  ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
> -
> -   if (pkt == ODP_PACKET_INVALID)
> -  

[lng-odp] [PATCH] example: generator : use packet reference API to generate udp and icmp traffic

2017-07-28 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 176 +++---
 1 file changed, 107 insertions(+), 69 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 9336cec..ef37328 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -136,6 +136,7 @@ static void millisleep(uint32_t ms,
uint64_t ticks = odp_timer_ns_to_tick(tp, 100ULL * ms);
odp_event_t ev = odp_timeout_to_event(tmo);
int rc = odp_timer_set_rel(tim, ticks, );
+
if (rc != ODP_TIMER_SUCCESS)
EXAMPLE_ABORT("odp_timer_set_rel() failed\n");
/* Spin waiting for timeout event */
@@ -186,12 +187,76 @@ static int scan_ip(char *buf, unsigned int *paddr)
 }
 
 /**
+ * Setup array of reference packets
+ *
+ * @param pool Packet pool
+ * @param pkt_ref_array Packet array
+ * @param pkt_ref_array_size Packet array size
+ * @param setup_ref Packet setup function
+ * @return 0 success, -1 failed
+*/
+static int setup_pkt_ref_array(odp_pool_t pool,
+  odp_packet_t *pkt_ref_array,
+  int pkt_ref_array_size,
+  odp_packet_t (*setup_ref)(odp_pool_t))
+{
+   int i;
+
+   for (i = 0; i < pkt_ref_array_size; i++) {
+   pkt_ref_array[i] = (*setup_ref)(pool);
+   if (pkt_ref_array[i] == ODP_PACKET_INVALID)
+   break;
+   }
+
+   if (i < pkt_ref_array_size) {
+   odp_packet_free_multi(pkt_ref_array, i);
+   return -1;
+   }
+   return 0;
+}
+
+/**
+ * Setup array of packets
+ *
+ * @param pkt_ref_array Reference packet array
+ * @param pkt_array Packet array
+ * @param pkt_array_size Packet array size
+ * @param setup_pkt Packet setup function
+ * @return 0 success, -1 failed
+*/
+static int setup_pkt_array(odp_packet_t *pkt_ref_array,
+  odp_packet_t  *pkt_array,
+  int pkt_array_size,
+  int (*setup_pkt)(odp_packet_t))
+{
+   int i;
+
+   for (i = 0; i < pkt_array_size; i++) {
+   if ((*setup_pkt)(pkt_ref_array[i]))
+   break;
+
+   pkt_array[i] = odp_packet_ref_static(pkt_ref_array[i]);
+   if (pkt_array[i] == ODP_PACKET_INVALID)
+   break;
+   }
+   if (i < pkt_array_size) {
+   if (i)
+   odp_packet_free_multi(pkt_array, i - 1);
+
+   return -1;
+   }
+   return 0;
+}
+
+/**
  * set up an udp packet reference
  *
  * @param pool Buffer pool to create packet in
  *
- * @return Handle of created packet
+ *
+ * @retval Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
+ *
  */
 static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
 {
@@ -246,37 +311,27 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
 /**
  * set up an udp packet
  *
- * @param pool Buffer pool to create packet in
- * @param pkt_ref Reference UDP packet
+ * @param pkt Reference UDP packet
  *
- * @return Handle of created packet
- * @retval ODP_PACKET_INVALID  Packet could not be created
+ * @return Success/Failed
+ * @retval 0 on success, -1 on fail
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static int setup_udp_pkt(odp_packet_t pkt)
 {
-   odp_packet_t pkt;
char *buf;
odph_ipv4hdr_t *ip;
unsigned short seq;
 
-   pkt = odp_packet_alloc(pool, args->appl.payload + ODPH_UDPHDR_LEN +
-  ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
-
-   if (pkt == ODP_PACKET_INVALID)
-   return pkt;
-
buf = (char *)odp_packet_data(pkt);
-   odp_memcpy(buf, odp_packet_data(pkt_ref),
-  args->appl.payload + ODPH_UDPHDR_LEN +
-  ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
 
/*Update IP ID and checksum*/
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
+   ip->chksum = 0;
ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
-   return pkt;
+   return 0;
 }
 
 /**
@@ -337,15 +392,13 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
 /**
  * Set up an icmp packet
  *
- * @param pool Buffer pool to create packet in
- * @param pkt_ref Reference ICMP packet
+ * @param pkt Reference ICMP packet
  *
- * @return Handle of created packet
- * @retval ODP_PACKET_INVALID  Packet could not be created
+ * @return Success/Failed
+ * @retval 0 on success, -1 on fail
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static int setup_icmp_pkt(odp_packet_t pkt)
 {
-   odp_packet_t pkt;
char *buf;
odph_ipv4hdr_t *ip;
odph_ic

[lng-odp] [PATCH] example: generator : use packet reference API

2017-07-28 Thread Bogdan Pricope
Use packet reference API to generate udp and icmp traffic.

Note:
 - To be applied on top of pktrefs v4 series
 - My test with odp-linux/default pktio shows a 5% increase in
performance on this usecase

Bogdan Pricope (1):
  example: generator : use packet reference API to generate udp and icmp
traffic

 example/generator/odp_generator.c | 176 +++---
 1 file changed, 107 insertions(+), 69 deletions(-)

-- 
1.9.1



Re: [lng-odp] [PATCH 0/6] dpdk pktio: enable hardware checksum support

2017-07-21 Thread Bogdan Pricope
Have a nice vacation, Matias!!
We will have time for this in the autumn...

On 21 July 2017 at 10:36, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> ok, don't worry, have a good time!
>
> On 21 July 2017 at 08:53, Elo, Matias (Nokia - FI/Espoo) <
> matias@nokia.com> wrote:
>
>> I'm starting my vacation today and have more acute things on my plate, so
>> I don't unfortunately have time to review the patch for a couple of weeks.
>>
>> -Matias
>>
>> > On 20 Jul 2017, at 23:16, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>> >
>> > Krishna, Matias, please review dpdk changes.
>> >
>> > Maxim.
>> >
>> > On 07/19/17 16:35, Bogdan Pricope wrote:
>> >> Ping?
>> >>
>> >> We still want this for odp-linux or we should implement it on odp-dpdk
>> >> only (as soon as repository is updated)?
>> >>
>> >> /B
>> >>
>> >> On 20 June 2017 at 12:20, Bogdan Pricope <bogdan.pric...@linaro.org>
>> wrote:
>> >>> Ping?
>> >>>
>> >>> On 31 May 2017 at 17:40, Bogdan Pricope <bogdan.pric...@linaro.org>
>> wrote:
>> >>>> Add HW checksum calculation/validation support for dpdk pktio.
>> >>>> No UDP/TCP HW checksum calculation/validation support for:
>> >>>> - IPv4 fragments
>> >>>> - IPv6 packets with extension headers (including fragments)
>> >>>>
>> >>>> Bogdan Pricope (6):
>> >>>>  Initialize pktio configuration structure
>> >>>>  dpdk: retrieve offload capabilities
>> >>>>  dpdk: enable per pktio RX IP/UDP/TCP checksum offload
>> >>>>  dpdk: RX - process checksum validation offload flags
>> >>>>  dpdk: TX - set checksum calculation offload flags
>> >>>>  examples: generator: update odp_generator to use HW checksum
>> >>>>capabilities
>> >>>>
>> >>>> example/generator/odp_generator.c  | 107 ++---
>> >>>> platform/linux-generic/odp_packet_io.c |   2 +
>> >>>> platform/linux-generic/pktio/dpdk.c| 203
>> -
>> >>>> 3 files changed, 293 insertions(+), 19 deletions(-)
>> >>>>
>> >>>> --
>> >>>> 1.9.1
>> >>>>
>> >
>>
>>


Re: [lng-odp] ODP traffic manager and comparison with DPDK

2017-07-20 Thread Bogdan Pricope
OFP (OpenFastPath) is a user space IP stack (IPv4/IPv6, UDP/TCP,
routes/arp, sockets, select(), epoll(), etc.) on top of ODP. See
http://www.openfastpath.org/


On 20 July 2017 at 11:44, Puneet Gupta  wrote:
> Hi all,
>
> I am understanding the ODP framework for last few days. I am have some 
> queries related to it.
>
>
>
> 1.   There is a traffic manager block in the egress direction . In the 
> diagram (section 5.3 in 
> https://docs.opendataplane.org/snapshots/odp-publish/generic/usr_html/master/latest/linux-generic/output/users-guide.html
>  ), it is shown that it has TM input queues and TM output queues. What does 
> that mean?? How these input queues are different from the ones which are 
> there in the ingress direction ( that are after the classifier)
>
> 2.   The queues which are created through the API odp_tm_queue_create ( 
> in which we associate shaper/wred profile), whether they are input queues or 
> output queues or both?
>
> 3.   How it is different from DPDK. I heard that it supports hardware 
> offload features such as classification , buffering , queueing etc wherease 
> dpdk doesn't. But is there any other reason why we should go with ODP and not 
> DDK?
>
> 4.   What is OFP. I couldn't understand why it has been created. I can 
> see that the main benefir of OFP is portability. But that portability feature 
> is already achieved by ODP.
>
> Thanks in advance
>
> -Puneet
>
>
>
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
>


Re: [lng-odp] [PATCH 0/6] dpdk pktio: enable hardware checksum support

2017-07-19 Thread Bogdan Pricope
Ping?

We still want this for odp-linux or we should implement it on odp-dpdk
only (as soon as repository is updated)?

/B

On 20 June 2017 at 12:20, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Ping?
>
> On 31 May 2017 at 17:40, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>> Add HW checksum calculation/validation support for dpdk pktio.
>> No UDP/TCP HW checksum calculation/validation support for:
>>  - IPv4 fragments
>>  - IPv6 packets with extension headers (including fragments)
>>
>> Bogdan Pricope (6):
>>   Initialize pktio configuration structure
>>   dpdk: retrieve offload capabilities
>>   dpdk: enable per pktio RX IP/UDP/TCP checksum offload
>>   dpdk: RX - process checksum validation offload flags
>>   dpdk: TX - set checksum calculation offload flags
>>   examples: generator: update odp_generator to use HW checksum
>> capabilities
>>
>>  example/generator/odp_generator.c  | 107 ++---
>>  platform/linux-generic/odp_packet_io.c |   2 +
>>  platform/linux-generic/pktio/dpdk.c| 203 
>> -
>>  3 files changed, 293 insertions(+), 19 deletions(-)
>>
>> --
>> 1.9.1
>>


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

2017-07-17 Thread Bogdan Pricope
Hi,

In DPDK case, default MTU is 1500:

/*
 * Set the default MTU.
 */
eth_dev->data->mtu = ETHER_MTU;


where:

#define ETHER_MTU   \

(ETHER_MAX_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN) /**<
Ethernet MTU. */


So, if you need to jumbo, you have to set MTU yourself (I guess dpdk
will not send the frames otherwise):

rte_eth_dev_set_mtu(pktio_entry->s.pkt_dpdk.portid, JUMBO_MTU_VALUE);

So, it depends on how underneath SDK is working …


BR,
Bogdan

On 14 July 2017 at 21:53, Bill Fischofer <bill.fischo...@linaro.org> wrote:
>
>
> On Fri, Jul 14, 2017 at 10:09 AM, Peltonen, Janne (Nokia - FI/Espoo)
> <janne.pelto...@nokia.com> wrote:
>>
>> Hi,
>>
>>
>>
>> I think MAC addresses and MTU are a bit different.
>>
>>
>>
>> There are valid use cases for application wanting to set the MAC address,
>> even dynamically. For instance, with VRRP one wants to receive packets
>> destined to a VRRP MAC address in addition to the fixed MAC address of a
>> port. The possibility of configuring multiple MAC addresses (for the purpose
>> of RX frame filtering) to the same port and changing them dynamically would
>> be useful to some apps.
>>
>> The physical MTU of a port is more like a capability, the maximum that the
>> port can do. The ODP application can then use any frame sizes it wants, up
>> to the maximum size, without configuring anything to ODP. e.g. IP layer MTUs
>> can be maintained by an IP stack application while the physical MTU at ODP
>> level stays at the fixed maximum. An application does not have a need to
>> tell ODP that the maximum frame size should be limited, but an ODP
>> implementation might conceivably wish to get such information from the
>> application or from elsewhere if supporting big frames (i.e. enabling jumbo
>> frames) involves some costs that the ODP implementation would rather avoid
>> if the application does not really need big frames.
>>
>>
>>
>> Even if MTU configuration is not added in ODP API, it is useful to be able
>> to query the maximum physical MTU of a port as that can vary also among HW
>> that supports pretty big frame sizes. The meaning of the returned MTU value
>> (i.e. which bytes are counted) should be clarified.
>
>
> I agree with this, however the historical reason for MTU was hardware
> limits. When a driver transmits a packet, the physical MAC stores the bytes
> of this packet in a FIFO (hardware registers) as the bits are clocked
> through the PHY layer. Historically these registers were costly, so
> minimizing them was important to meet needed price points. Today, as silicon
> prices have fallen dramatically and even low-end processors have
> multi-megabyte caches, there's little cost reasons for such low physical
> limits. Moreover, at 10Gb and above speeds, you don't want to be filling the
> pipe with IPG and framing bits, so larger packet sizes are inherently more
> efficient. The result is that it's very difficult to fine a NIC in any
> modern system that doesn't support jumbo frames, so the utility of setting
> the MTU to anything other than 9K (especially for link speeds of interest to
> ODP applications) is questionable.
>
>>
>>
>>
>>  Janne
>>
>>
>>
>>
>>
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Friday, July 14, 2017 5:39 PM
>> To: Bogdan Pricope <bogdan.pric...@linaro.org>; Petri Savolainen
>> <petri.savolai...@linaro.org>
>> Cc: Narayana Prasad Athreya <pathr...@caviumnetworks.com>; Peltonen, Janne
>> (Nokia - FI/Espoo) <janne.pelto...@nokia.com>; mcha...@cavium.com;
>> lng-odp@lists.linaro.org; pathr...@cavium.com; vattun...@cavium.com;
>> sve...@cavium.com
>> Subject: Re: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the MAC
>> address and MTU size.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 14, 2017 at 9:11 AM, Bogdan Pricope
>> <bogdan.pric...@linaro.org> wrote:
>>
>> Hi,
>>
>> I think we need both MTU and MAC address to be settable from ODP.
>>
>> In OFP, at some point I was considering using tap pktio instead of ofp
>> tap interface for slow path processing - not being able to set MAC
>> address was A problem.
>> What about DHCP by MAC address? Maybe there are systems where
>> predefined MAC address is a requirement... don't know...
>>
>> MTU: what if default value is not 9K but something else?
>>
>>
>>
>> I'll add this to the agenda for Monday's ARCH call. If Petri (+cc) wants
>> to chime in before he leaves for v

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

2017-07-14 Thread Bogdan Pricope
Hi,

I think we need both MTU and MAC address to be settable from ODP.

In OFP, at some point I was considering using tap pktio instead of ofp
tap interface for slow path processing - not being able to set MAC
address was A problem.
What about DHCP by MAC address? Maybe there are systems where
predefined MAC address is a requirement... don't know...

MTU: what if default value is not 9K but something else?

BR,
Bogdan


On 14 July 2017 at 16:41, Narayana Prasad Athreya
 wrote:
> Hi Bill
> The reasons below dont jive with what ODP does today. If the routines
> odp_pktio_mtu() and odp_pktio_mac_addr() exist today. They assume that MTU
> can be configured and returned to the datapath. As an application developer,
> it does make sense for me to use 2 different paths to talk to the same
> underlying device for the same setting - one path for configuring and one
> for reading the configuration.
>
> So from this standpoint the ODP should either support both get and set
> routines or not support either of them.
>
> On the control-plane vs data-plane debate, again as an application
> developer, my integrated application will need access to the underlying
> device for both control and data. If i am forced to right separate code and
> potentially drivers for 2 paths, where is my incentive to use ODP API,
> because anyway i'm losing portability.
>
> Thanks
> Prasad
>
> On Friday 14 July 2017 06:33 PM, Bill Fischofer wrote:
>>
>>
>>
>> On Fri, Jul 14, 2017 at 6:05 AM, Peltonen, Janne (Nokia - FI/Espoo)
>> > wrote:
>>
>> Hi,
>>
>> ODP API should somewhere define what exactly MTU means in the
>> context of ODP.
>>
>> One can guess that transmission and reception of L2 frames larger
>> than the
>> configured MTU is not guaranteed to succeed, but which bytes are
>> taken into
>> account? For instance, is Ethernet FCS counted towards the MTU?
>>
>>
>> We've had this discussion before. The whole concept of MTU is a bit of an
>> anachronism from the early days of Ethernet. At speeds ODP is designed for
>> (10Gb and above) all equipment should be running with jumbo frames (MTU =
>> 9K). All equipment capable of running at these speeds is capable of this
>> size, and 9K is the recommended default MTU for this equipment. So there's
>> really nothing one should need to control or change here.
>>
>> It would be interesting to understand the use case that is driving the
>> desire to be able to set MTU.
>>
>> The other consideration is that setting MTU (or MAC address) is a control
>> plane function, not a data plane function. Just as the control plane tells
>> the data plane which interfaces to use, the control plane is responsible for
>> this type of configuration, as well as managing and responding to
>> configuration changes. So again, it would be good to understand the use case
>> behind wanting to change these values in the data plane.
>>
>>
>> Janne
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
>> ] On Behalf Of Vamsi Attunuru
>> > Sent: Friday, July 14, 2017 1:05 PM
>> > To: lng-odp@lists.linaro.org 
>> > Cc: mcha...@cavium.com ;
>> pathr...@cavium.com ;
>> vattun...@cavium.com ;
>> sve...@cavium.com 
>> > Subject: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the
>> MAC address and MTU size.
>> >
>> > Adds new pktio APIs to set MTU and MAC address on pktio interface.
>> >
>> > Signed-off-by: Vamsi Attunuru > >
>> > Signed-off-by: Mahipal Challa > >
>> > Signed-off-by: Shally Verma   > >
>> >
>> > ---
>> >  include/odp/api/spec/packet_io.h | 45
>> 
>>
>> >  1 file changed, 45 insertions(+)
>> >
>> > diff --git a/include/odp/api/spec/packet_io.h
>> b/include/odp/api/spec/packet_io.h
>> > index 8802089..1269f44 100644
>> > --- a/include/odp/api/spec/packet_io.h
>> > +++ b/include/odp/api/spec/packet_io.h
>> > @@ -451,6 +451,10 @@ typedef union odp_pktio_set_op_t {
>> >   struct {
>> >   /** Promiscuous mode */
>> >   uint32_t promisc_mode : 1;
>> > + /** MAC address */
>> > + uint32_t mac : 1;
>> > + /** MTU size */
>> > + uint32_t mtu : 1;
>> >   } op;
>> >   /** All bits of the bit field structure.
>> > * This field can be used to set/clear all flags, or bitwise
>> > @@ -482,6 +486,12 @@ typedef struct 

Re: [lng-odp] [API-NEXT PATCH 3/9] api: ipsec: direction specific SA params

2017-07-12 Thread Bogdan Pricope
Fine with me.

BR,
Bogdan

On 11 July 2017 at 15:31, Petri Savolainen <petri.savolai...@linaro.org> wrote:
> Move direction (inboud/outbound) specific SA parameters
> into separate structures. Specification is more clear
> between common and direction specific SA parameters.
>
> Signed-off-by: Petri Savolainen <petri.savolai...@linaro.org>
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  include/odp/api/spec/ipsec.h | 103 
> +--
>  1 file changed, 59 insertions(+), 44 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index 388c9f38..5e5c87ec 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -630,51 +630,18 @@ typedef struct odp_ipsec_sa_param_t {
> /** Parameters for crypto and authentication algorithms */
> odp_ipsec_crypto_param_t crypto;
>
> -   /** Parameters for tunnel mode */
> -   odp_ipsec_tunnel_param_t tunnel;
> -
> -   /** Fragmentation mode */
> -   odp_ipsec_frag_mode_t frag_mode;
> -
> /** Various SA option flags */
> odp_ipsec_sa_opt_t opt;
>
> /** SA lifetime parameters */
> odp_ipsec_lifetime_t lifetime;
>
> -   /** SA lookup mode */
> -   odp_ipsec_lookup_mode_t lookup_mode;
> -
> -   /** Minimum anti-replay window size. Use 0 to disable anti-replay
> - * service. */
> -   uint32_t antireplay_ws;
> -
> /** Initial sequence number */
> uint64_t seq;
>
> /** SPI value */
> uint32_t spi;
>
> -   /** Additional inbound SA lookup parameters. Values are considered
> -*  only in ODP_IPSEC_LOOKUP_DSTADDR_SPI lookup mode. */
> -   struct {
> -   /** Select IP version
> -*/
> -   odp_ipsec_ip_version_t ip_version;
> -
> -   /** IP destination address (NETWORK ENDIAN) */
> -   void*dst_addr;
> -
> -   } lookup_param;
> -
> -   /** MTU for outbound IP fragmentation offload
> -*
> -*  This is the maximum length of IP packets that outbound IPSEC
> -*  operations may produce. The value may be updated later with
> -*  odp_ipsec_mtu_update().
> -*/
> -   uint32_t mtu;
> -
> /** Select pipelined destination for resulting events
>  *
>  *  Asynchronous and inline modes generate events. Select where
> @@ -691,17 +658,6 @@ typedef struct odp_ipsec_sa_param_t {
>  */
> odp_queue_t dest_queue;
>
> -   /** Classifier destination CoS for resulting packets
> -*
> -*  Successfully decapsulated packets are sent to classification
> -*  through this CoS. Other resulting events are sent to 'dest_queue'.
> -*  This field is considered only when 'pipeline' is
> -*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any 
> pktio
> -*  interface default CoS. The maximum number of different CoS 
> supported
> -*  is defined by IPSEC capability max_cls_cos.
> -*/
> -   odp_cos_t dest_cos;
> -
> /** User defined SA context pointer
>  *
>  *  User defined context pointer associated with the SA.
> @@ -718,6 +674,65 @@ typedef struct odp_ipsec_sa_param_t {
>  */
> uint32_t context_len;
>
> +   /** IPSEC SA direction dependent parameters */
> +   union {
> +   /** Inbound specific parameters */
> +   struct {
> +   /** SA lookup mode */
> +   odp_ipsec_lookup_mode_t lookup_mode;
> +
> +   /** Additional SA lookup parameters. Values are
> +*  considered only in ODP_IPSEC_LOOKUP_DSTADDR_SPI
> +*  lookup mode. */
> +   struct {
> +   /** Select IP version */
> +   odp_ipsec_ip_version_t ip_version;
> +
> +   /** IP destination address (NETWORK ENDIAN) to
> +*  be matched in addition to SPI value. */
> +   void *dst_addr;
> +
> +   } lookup_param;
> +
> +   /** Minimum anti-replay window size. Use 0 to disable
> +*  anti-replay service.
> +*/
> +   uint32_t antireplay_ws;
> +
> +   /** Classifier destination CoS for resulting packets
> +*
> 

[lng-odp] [RFCv2] ddf: example: build module with dpdk support

2017-06-29 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/ddf_app/odp_ddf_app.c|  14 +++-
 example/ddf_ifs/Makefile.am  |   9 ++-
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c | 126 ++-
 example/m4/configure.m4  |   2 +
 example/m4/example_dpdk.m4   |  43 
 scripts/build-example-ddf-dpdk   |  33 +
 6 files changed, 223 insertions(+), 4 deletions(-)
 create mode 100644 example/m4/example_dpdk.m4
 create mode 100755 scripts/build-example-ddf-dpdk

diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c
index af864ee..18c6994 100644
--- a/example/ddf_app/odp_ddf_app.c
+++ b/example/ddf_app/odp_ddf_app.c
@@ -20,9 +20,12 @@
 int main(int argc, char *argv[])
 {
odp_instance_t instance;
+   odp_pktio_t pktio = ODP_PKTIO_INVALID;
 
-   (void)argc;
-   (void)argv;
+   if (argc == 1 || argc > 2) {
+   printf("Error: invalid parameter.\nUsage:\n\t%s \n", 
argv[0]);
+   exit(0);
+   }
 
EXAMPLE_DBG("Start DDF Application...\n");
 
@@ -40,6 +43,13 @@ int main(int argc, char *argv[])
/* Print ddf objects*/
odpdrv_print_all();
 
+   /* Open pktio*/
+   /*odp_pktio_open();*/
+
+   /* Close pktio*/
+   if (odp_pktio_close(pktio))
+   EXAMPLE_ERR("Error: Failed to close pktio \"%s\".\n", argv[1]);
+
/* Terminate ODP */
odp_term_local();
odp_term_global(instance);
diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am
index aa892ac..77e56e6 100644
--- a/example/ddf_ifs/Makefile.am
+++ b/example/ddf_ifs/Makefile.am
@@ -3,7 +3,14 @@ LIB   = $(top_builddir)/lib
 AM_CPPFLAGS +=  -I$(srcdir) \
-I$(top_srcdir)/include \
-I$(top_srcdir)/platform/@with_platform@/include \
-   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@
+   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@ \
+   -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@ \
+   -I$(top_builddir)/include
+
+if EXAMPLE_DPDK_SUPPORT 
+AM_CPPFLAGS += @EXAMPLE_DPDK_CPPFLAGS@
+AM_LDFLAGS += @EXAMPLE_DPDK_LDFLAGS@
+endif
 
 lib_LTLIBRARIES = $(LIB)/libddf_ifs.la
 
diff --git a/example/ddf_ifs/ddf_ifs_enumr_dpdk.c 
b/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
index 782f7b7..25585dc 100644
--- a/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
+++ b/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
@@ -4,12 +4,27 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
+#include 
+
 #include 
+#include 
+#include 
+#include 
+
 #include "odp_drv.h"
 #include "ddf_ifs_api.h"
 #include "ddf_ifs_enumr_dpdk.h"
 #include "ddf_ifs_dev_dpdk.h"
 
+/*#include */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
 static odpdrv_enumr_t dpdk_enumr;
 
 #define TEST_DPDK_DEV_CNT 3
@@ -17,6 +32,106 @@ static odpdrv_enumr_t dpdk_enumr;
 
 static odpdrv_device_t dpdk_dev[DDF_DPDK_DEV_MAX];
 static int dpdk_dev_cnt;
+
+#define DPDK_MEMORY_MB 512
+static int dpdk_pktio_init(void)
+{
+   int dpdk_argc;
+   int i;
+   odp_cpumask_t mask;
+   char mask_str[ODP_CPUMASK_STR_SIZE];
+   const char *cmdline;
+   int32_t masklen;
+   int mem_str_len;
+   int cmd_len;
+   cpu_set_t original_cpuset;
+   struct rte_config *cfg;
+
+   /**
+* DPDK init changes the affinity of the calling thread, so after it
+* returns the original affinity is restored. Only the first active
+* core is passed to rte_eal_init(), as the rest would be used for
+* DPDK's special lcore threads, which are only available through
+* rte_eal_[mp_]remote_launch(), but not through ODP API's.
+* Nevertheless, odp_local_init() makes sure for the rest of
+* the DPDK libraries ODP threads look like proper DPDK threads.
+*/
+   CPU_ZERO(_cpuset);
+   i = pthread_getaffinity_np(pthread_self(),
+  sizeof(original_cpuset), _cpuset);
+   if (i != 0) {
+   printf("Failed to read thread affinity: %d\n", i);
+   return -1;
+   }
+
+   odp_cpumask_zero();
+   for (i = 0; i < CPU_SETSIZE; i++) {
+   if (CPU_ISSET(i, _cpuset)) {
+   odp_cpumask_set(, i);
+   break;
+   }
+   }
+   masklen = odp_cpumask_to_str(, mask_str, ODP_CPUMASK_STR_SIZE);
+
+   if (masklen < 0) {
+   printf("CPU mask error: %d\n", masklen);
+   return -1;
+   }
+
+   mem_str_len = snprintf(NULL, 0, "%d", DPDK_MEMORY_MB);
+
+   cmdline = getenv("ODP_PKTIO_DPDK_PARAMS");
+   if (cmdline == NULL)
+   cmdline = "";
+
+   /* masklen includes the terminating null as well */
+   cmd_len = strlen("d

[lng-odp] [RFCv2] ddf: examples: module with dpdk support

2017-06-29 Thread Bogdan Pricope
v2:
 Fix linking with dpdk shared libraries

v1:
This RFC shows how to build a DDF module with DPDK support while application
and odp have no DPDK support.

Step 1: Run 'build-example-ddf-dpdk' script.
e.g:
$ ./scripts/build-example-ddf-dpdk

This will:
 - clone dpdk
 - configure dpdk to build as shared libs
 - build dpdk
 - build odp with 'with-example-dpdk-path' option: this path to dpdk install
folder will be used by examples applications (if needed)

Only 'ddf_ifs' is built with dpdk support.

Step 2: Set LD_LIBRARY_PATH
 # export LD_LIBRARY_PATH=/odp/lib/.libs:/odp/dpdk/x86_64-native-linuxapp-gcc/lib

Step 3: Run the application
 # ODP_SYSCONFIG_FILE=/odp/example/ddf_ifs/odp.conf 
./example/ddf_app/.libs/odp_ddf_app ddf_pktio_name

Bogdan Pricope (1):
  ddf: example: build module with dpdk support

 example/ddf_app/odp_ddf_app.c|  14 +++-
 example/ddf_ifs/Makefile.am  |   9 ++-
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c | 126 ++-
 example/m4/configure.m4  |   2 +
 example/m4/example_dpdk.m4   |  43 
 scripts/build-example-ddf-dpdk   |  33 +
 6 files changed, 223 insertions(+), 4 deletions(-)
 create mode 100644 example/m4/example_dpdk.m4
 create mode 100755 scripts/build-example-ddf-dpdk

-- 
1.9.1



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

2017-06-29 Thread Bogdan Pricope
Ping!

On 22 June 2017 at 09:55, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  include/odp/api/spec/ipsec.h | 114 
> ---
>  1 file changed, 63 insertions(+), 51 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index e602e4b..5373ede 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -604,8 +604,8 @@ typedef enum odp_ipsec_ip_version_t {
>   * IPSEC Security Association (SA) parameters
>   */
>  typedef struct odp_ipsec_sa_param_t {
> -   /** IPSEC SA direction: inbound or outbound */
> -   odp_ipsec_dir_t dir;
> +   /** SPI value */
> +   uint32_t spi;
>
> /** IPSEC protocol: ESP or AH */
> odp_ipsec_protocol_t proto;
> @@ -616,51 +616,12 @@ typedef struct odp_ipsec_sa_param_t {
> /** Parameters for crypto and authentication algorithms */
> odp_ipsec_crypto_param_t crypto;
>
> -   /** Parameters for tunnel mode */
> -   odp_ipsec_tunnel_param_t tunnel;
> -
> -   /** Fragmentation mode */
> -   odp_ipsec_frag_mode_t frag_mode;
> -
> -   /** Various SA option flags */
> -   odp_ipsec_sa_opt_t opt;
> -
> /** SA lifetime parameters */
> odp_ipsec_lifetime_t lifetime;
>
> -   /** SA lookup mode */
> -   odp_ipsec_lookup_mode_t lookup_mode;
> -
> -   /** Minimum anti-replay window size. Use 0 to disable anti-replay
> - * service. */
> -   uint32_t antireplay_ws;
> -
> /** Initial sequence number */
> uint64_t seq;
>
> -   /** SPI value */
> -   uint32_t spi;
> -
> -   /** Additional inbound SA lookup parameters. Values are considered
> -*  only in ODP_IPSEC_LOOKUP_DSTADDR_SPI lookup mode. */
> -   struct {
> -   /** Select IP version
> -*/
> -   odp_ipsec_ip_version_t ip_version;
> -
> -   /** IP destination address (NETWORK ENDIAN) */
> -   void*dst_addr;
> -
> -   } lookup_param;
> -
> -   /** MTU for outbound IP fragmentation offload
> -*
> -*  This is the maximum length of IP packets that outbound IPSEC
> -*  operations may produce. The value may be updated later with
> -*  odp_ipsec_mtu_update().
> -*/
> -   uint32_t mtu;
> -
> /** Select pipelined destination for resulting events
>  *
>  *  Asynchronous and inline modes generate events. Select where
> @@ -677,16 +638,67 @@ typedef struct odp_ipsec_sa_param_t {
>  */
> odp_queue_t dest_queue;
>
> -   /** Classifier destination CoS for resulting packets
> -*
> -*  Successfully decapsulated packets are sent to classification
> -*  through this CoS. Other resulting events are sent to 'dest_queue'.
> -*  This field is considered only when 'pipeline' is
> -*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any 
> pktio
> -*  interface default CoS. The maximum number of different CoS 
> supported
> -*  is defined by IPSEC capability max_cls_cos.
> -*/
> -   odp_cos_t dest_cos;
> +   /** IPSEC SA direction: inbound or outbound */
> +   odp_ipsec_dir_t dir;
> +
> +   /** IPSEC SA direction dependent parameters */
> +   union {
> +   /** Inbound specific parameters */
> +   struct {
> +   /** SA lookup mode */
> +   odp_ipsec_lookup_mode_t lookup_mode;
> +
> +   /** Additional inbound SA lookup parameters. Values 
> are
> +   *  considered only in ODP_IPSEC_LOOKUP_DSTADDR_SPI
> +   *  lookup mode. */
> +   struct {
> +   /** Select IP version
> +   */
> +   odp_ipsec_ip_version_t ip_version;
> +
> +   /** IP destination address (NETWORK ENDIAN) */
> +   void*dst_addr;
> +
> +   } lookup_param;
> +
> +   /** Minimum anti-replay window size. Use 0 to disable
> +   *  anti-replay service. */
> +   uint32_t antireplay_ws;
> +
> +   /** Classifier destination CoS for resulting packets
> +   *
> +   *  Successfully decapsulated packets are sent to
> +   *  classification

[lng-odp] [RFC] ddf: example: build module with dpdk support

2017-06-27 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/ddf_app/odp_ddf_app.c|  14 +++-
 example/ddf_ifs/Makefile.am  |   9 ++-
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c | 126 ++-
 example/m4/configure.m4  |   2 +
 example/m4/example_dpdk.m4   |  57 
 scripts/build-example-ddf-dpdk   |  33 +
 6 files changed, 237 insertions(+), 4 deletions(-)
 create mode 100644 example/m4/example_dpdk.m4
 create mode 100755 scripts/build-example-ddf-dpdk

diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c
index af864ee..18c6994 100644
--- a/example/ddf_app/odp_ddf_app.c
+++ b/example/ddf_app/odp_ddf_app.c
@@ -20,9 +20,12 @@
 int main(int argc, char *argv[])
 {
odp_instance_t instance;
+   odp_pktio_t pktio = ODP_PKTIO_INVALID;
 
-   (void)argc;
-   (void)argv;
+   if (argc == 1 || argc > 2) {
+   printf("Error: invalid parameter.\nUsage:\n\t%s \n", 
argv[0]);
+   exit(0);
+   }
 
EXAMPLE_DBG("Start DDF Application...\n");
 
@@ -40,6 +43,13 @@ int main(int argc, char *argv[])
/* Print ddf objects*/
odpdrv_print_all();
 
+   /* Open pktio*/
+   /*odp_pktio_open();*/
+
+   /* Close pktio*/
+   if (odp_pktio_close(pktio))
+   EXAMPLE_ERR("Error: Failed to close pktio \"%s\".\n", argv[1]);
+
/* Terminate ODP */
odp_term_local();
odp_term_global(instance);
diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am
index aa892ac..77e56e6 100644
--- a/example/ddf_ifs/Makefile.am
+++ b/example/ddf_ifs/Makefile.am
@@ -3,7 +3,14 @@ LIB   = $(top_builddir)/lib
 AM_CPPFLAGS +=  -I$(srcdir) \
-I$(top_srcdir)/include \
-I$(top_srcdir)/platform/@with_platform@/include \
-   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@
+   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@ \
+   -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@ \
+   -I$(top_builddir)/include
+
+if EXAMPLE_DPDK_SUPPORT 
+AM_CPPFLAGS += @EXAMPLE_DPDK_CPPFLAGS@
+AM_LDFLAGS += @EXAMPLE_DPDK_LDFLAGS@
+endif
 
 lib_LTLIBRARIES = $(LIB)/libddf_ifs.la
 
diff --git a/example/ddf_ifs/ddf_ifs_enumr_dpdk.c 
b/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
index 782f7b7..25585dc 100644
--- a/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
+++ b/example/ddf_ifs/ddf_ifs_enumr_dpdk.c
@@ -4,12 +4,27 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
+#include 
+
 #include 
+#include 
+#include 
+#include 
+
 #include "odp_drv.h"
 #include "ddf_ifs_api.h"
 #include "ddf_ifs_enumr_dpdk.h"
 #include "ddf_ifs_dev_dpdk.h"
 
+/*#include */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
 static odpdrv_enumr_t dpdk_enumr;
 
 #define TEST_DPDK_DEV_CNT 3
@@ -17,6 +32,106 @@ static odpdrv_enumr_t dpdk_enumr;
 
 static odpdrv_device_t dpdk_dev[DDF_DPDK_DEV_MAX];
 static int dpdk_dev_cnt;
+
+#define DPDK_MEMORY_MB 512
+static int dpdk_pktio_init(void)
+{
+   int dpdk_argc;
+   int i;
+   odp_cpumask_t mask;
+   char mask_str[ODP_CPUMASK_STR_SIZE];
+   const char *cmdline;
+   int32_t masklen;
+   int mem_str_len;
+   int cmd_len;
+   cpu_set_t original_cpuset;
+   struct rte_config *cfg;
+
+   /**
+* DPDK init changes the affinity of the calling thread, so after it
+* returns the original affinity is restored. Only the first active
+* core is passed to rte_eal_init(), as the rest would be used for
+* DPDK's special lcore threads, which are only available through
+* rte_eal_[mp_]remote_launch(), but not through ODP API's.
+* Nevertheless, odp_local_init() makes sure for the rest of
+* the DPDK libraries ODP threads look like proper DPDK threads.
+*/
+   CPU_ZERO(_cpuset);
+   i = pthread_getaffinity_np(pthread_self(),
+  sizeof(original_cpuset), _cpuset);
+   if (i != 0) {
+   printf("Failed to read thread affinity: %d\n", i);
+   return -1;
+   }
+
+   odp_cpumask_zero();
+   for (i = 0; i < CPU_SETSIZE; i++) {
+   if (CPU_ISSET(i, _cpuset)) {
+   odp_cpumask_set(, i);
+   break;
+   }
+   }
+   masklen = odp_cpumask_to_str(, mask_str, ODP_CPUMASK_STR_SIZE);
+
+   if (masklen < 0) {
+   printf("CPU mask error: %d\n", masklen);
+   return -1;
+   }
+
+   mem_str_len = snprintf(NULL, 0, "%d", DPDK_MEMORY_MB);
+
+   cmdline = getenv("ODP_PKTIO_DPDK_PARAMS");
+   if (cmdline == NULL)
+   cmdline = "";
+
+   /* masklen includes the terminating null as well */
+   cmd_len = strlen("d

[lng-odp] [RFC] ddf: examples: module with dpdk support

2017-06-27 Thread Bogdan Pricope
This RFC shows how to build a DDF module with DPDK support while application
and odp have no DPDK support.

Step 1: Run 'build-example-ddf-dpdk' script.
e.g:
$ ./scripts/build-example-ddf-dpdk

This will:
 - clone dpdk
 - configure dpdk to build as shared libs
 - build dpdk
 - build odp with 'with-example-dpdk-path' option: this path to dpdk install
 folder will be used by examples applications (if needed)

Only 'ddf_ifs' is built with dpdk support.

Step 2: Set LD_LIBRARY_PATH
 # export LD_LIBRARY_PATH=/odp/lib/.libs:/odp/dpdk/x86_64-native-linuxapp-gcc/lib

Step 3: Run the application 
 # ODP_SYSCONFIG_FILE=/odp/example/ddf_ifs/odp.conf 
./example/ddf_app/.libs/odp_ddf_app ddf_pktio_name

Note: rte_eal_init() runs OK; yet, rte_eth_dev_count() returns 0... it may 
still need some work.

Bogdan Pricope (1):
  ddf: example: build module with dpdk support

 example/ddf_app/odp_ddf_app.c|  14 +++-
 example/ddf_ifs/Makefile.am  |   9 ++-
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c | 126 ++-
 example/m4/configure.m4  |   2 +
 example/m4/example_dpdk.m4   |  57 
 scripts/build-example-ddf-dpdk   |  33 +
 6 files changed, 237 insertions(+), 4 deletions(-)
 create mode 100644 example/m4/example_dpdk.m4
 create mode 100755 scripts/build-example-ddf-dpdk

-- 
1.9.1



[lng-odp] [CLOUD-DEVv2] ddf: examples: add ddf module skeleton and ddf application

2017-06-22 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/Makefile.am |  4 +-
 example/ddf_app/Makefile.am | 10 
 example/ddf_app/odp_ddf_app.c   | 49 +++
 example/ddf_ifs/Makefile.am | 27 +++
 example/ddf_ifs/ddf_ifs.c   | 28 +++
 example/ddf_ifs/ddf_ifs.h   | 18 +++
 example/ddf_ifs/ddf_ifs_api.h   | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.c  | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.h  | 24 +
 example/ddf_ifs/ddf_ifs_devio_direct.c  | 51 +++
 example/ddf_ifs/ddf_ifs_devio_direct.h  | 20 
 example/ddf_ifs/ddf_ifs_driver.c| 69 ++
 example/ddf_ifs/ddf_ifs_driver.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_class.c   | 47 ++
 example/ddf_ifs/ddf_ifs_enumr_class.h   | 20 
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 +
 example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++
 example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 
 example/ddf_ifs/odp.conf|  4 ++
 example/m4/configure.m4 |  2 +
 21 files changed, 625 insertions(+), 1 deletion(-)
 create mode 100644 example/ddf_app/Makefile.am
 create mode 100644 example/ddf_app/odp_ddf_app.c
 create mode 100644 example/ddf_ifs/Makefile.am
 create mode 100644 example/ddf_ifs/ddf_ifs.c
 create mode 100644 example/ddf_ifs/ddf_ifs.h
 create mode 100644 example/ddf_ifs/ddf_ifs_api.h
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.c
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h
 create mode 100644 example/ddf_ifs/odp.conf

diff --git a/example/Makefile.am b/example/Makefile.am
index dfc07b6..b209585 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -8,4 +8,6 @@ SUBDIRS = classifier \
  switch \
  time \
  timer \
- traffic_mgmt
+ traffic_mgmt \
+ ddf_ifs \
+ ddf_app
diff --git a/example/ddf_app/Makefile.am b/example/ddf_app/Makefile.am
new file mode 100644
index 000..e654202
--- /dev/null
+++ b/example/ddf_app/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_ddf_app$(EXEEXT)
+odp_ddf_app_LDFLAGS = $(AM_LDFLAGS) -shared
+odp_ddf_app_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_ddf_app_SOURCES = odp_ddf_app.c
diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c
new file mode 100644
index 000..af864ee
--- /dev/null
+++ b/example/ddf_app/odp_ddf_app.c
@@ -0,0 +1,49 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/** enable strtok */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char *argv[])
+{
+   odp_instance_t instance;
+
+   (void)argc;
+   (void)argv;
+
+   EXAMPLE_DBG("Start DDF Application...\n");
+
+   /* Initialize ODP before calling anything else */
+   if (odp_init_global(, NULL, NULL)) {
+   EXAMPLE_ERR("Error: ODP global init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   if (odp_init_local(instance, ODP_THREAD_CONTROL)) {
+   EXAMPLE_ERR("Error: ODP local init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   /* Print ddf objects*/
+   odpdrv_print_all();
+
+   /* Terminate ODP */
+   odp_term_local();
+   odp_term_global(instance);
+
+   EXAMPLE_DBG("Exit DDF Application.\n");
+   return 0;
+}
diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am
new file mode 100644
index 000..aa892ac
--- /dev/null
+++ b/example/ddf_ifs/Makefile.am
@@ -0,0 +1,27 @@
+LIB   = $(top_builddir)/lib
+
+AM_CPPFLAGS +=  -I$(srcdir) \
+   -I$(top_srcdir)/include \
+   -I$(top_srcdir)/platform/@with_platform@/include \
+   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@
+
+lib_LTLIBRARIES = $(LIB)/libddf_ifs.la
+
+noinst_HEADERS = \
+$(srcdir)/ddf_ifs.h \
+$(srcdir)/ddf

[lng-odp] [CLOUD-DEVv2] ddf: examples: ddf module skeleton

2017-06-22 Thread Bogdan Pricope
This patch contains a ddf module skeleton (example) and a ddf model application.
Was designed to highlight (print) DDF operations/steps.

Module is loaded at init_global time through odp configuration file (modules 
section).

Usage:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/odp/lib/.libs

ODP_SYSCONFIG_FILE=/home/odp/example/ddf_ifs/odp.conf 
./example/ddf_app/odp_ddf_app

v2:
  - update copyright text
  - fix distcheck build

Bogdan Pricope (1):
  ddf: examples: add ddf module skeleton and ddf application

 example/Makefile.am |  4 +-
 example/ddf_app/Makefile.am | 10 
 example/ddf_app/odp_ddf_app.c   | 49 +++
 example/ddf_ifs/Makefile.am | 27 +++
 example/ddf_ifs/ddf_ifs.c   | 28 +++
 example/ddf_ifs/ddf_ifs.h   | 18 +++
 example/ddf_ifs/ddf_ifs_api.h   | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.c  | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.h  | 24 +
 example/ddf_ifs/ddf_ifs_devio_direct.c  | 51 +++
 example/ddf_ifs/ddf_ifs_devio_direct.h  | 20 
 example/ddf_ifs/ddf_ifs_driver.c| 69 ++
 example/ddf_ifs/ddf_ifs_driver.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_class.c   | 47 ++
 example/ddf_ifs/ddf_ifs_enumr_class.h   | 20 
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 +
 example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++
 example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 
 example/ddf_ifs/odp.conf|  4 ++
 example/m4/configure.m4 |  2 +
 21 files changed, 625 insertions(+), 1 deletion(-)
 create mode 100644 example/ddf_app/Makefile.am
 create mode 100644 example/ddf_app/odp_ddf_app.c
 create mode 100644 example/ddf_ifs/Makefile.am
 create mode 100644 example/ddf_ifs/ddf_ifs.c
 create mode 100644 example/ddf_ifs/ddf_ifs.h
 create mode 100644 example/ddf_ifs/ddf_ifs_api.h
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.c
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h
 create mode 100644 example/ddf_ifs/odp.conf

-- 
1.9.1



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

2017-06-22 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 include/odp/api/spec/ipsec.h | 114 ---
 1 file changed, 63 insertions(+), 51 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index e602e4b..5373ede 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -604,8 +604,8 @@ typedef enum odp_ipsec_ip_version_t {
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
-   /** IPSEC SA direction: inbound or outbound */
-   odp_ipsec_dir_t dir;
+   /** SPI value */
+   uint32_t spi;
 
/** IPSEC protocol: ESP or AH */
odp_ipsec_protocol_t proto;
@@ -616,51 +616,12 @@ typedef struct odp_ipsec_sa_param_t {
/** Parameters for crypto and authentication algorithms */
odp_ipsec_crypto_param_t crypto;
 
-   /** Parameters for tunnel mode */
-   odp_ipsec_tunnel_param_t tunnel;
-
-   /** Fragmentation mode */
-   odp_ipsec_frag_mode_t frag_mode;
-
-   /** Various SA option flags */
-   odp_ipsec_sa_opt_t opt;
-
/** SA lifetime parameters */
odp_ipsec_lifetime_t lifetime;
 
-   /** SA lookup mode */
-   odp_ipsec_lookup_mode_t lookup_mode;
-
-   /** Minimum anti-replay window size. Use 0 to disable anti-replay
- * service. */
-   uint32_t antireplay_ws;
-
/** Initial sequence number */
uint64_t seq;
 
-   /** SPI value */
-   uint32_t spi;
-
-   /** Additional inbound SA lookup parameters. Values are considered
-*  only in ODP_IPSEC_LOOKUP_DSTADDR_SPI lookup mode. */
-   struct {
-   /** Select IP version
-*/
-   odp_ipsec_ip_version_t ip_version;
-
-   /** IP destination address (NETWORK ENDIAN) */
-   void*dst_addr;
-
-   } lookup_param;
-
-   /** MTU for outbound IP fragmentation offload
-*
-*  This is the maximum length of IP packets that outbound IPSEC
-*  operations may produce. The value may be updated later with
-*  odp_ipsec_mtu_update().
-*/
-   uint32_t mtu;
-
/** Select pipelined destination for resulting events
 *
 *  Asynchronous and inline modes generate events. Select where
@@ -677,16 +638,67 @@ typedef struct odp_ipsec_sa_param_t {
 */
odp_queue_t dest_queue;
 
-   /** Classifier destination CoS for resulting packets
-*
-*  Successfully decapsulated packets are sent to classification
-*  through this CoS. Other resulting events are sent to 'dest_queue'.
-*  This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS. The maximum number of different CoS supported
-*  is defined by IPSEC capability max_cls_cos.
-*/
-   odp_cos_t dest_cos;
+   /** IPSEC SA direction: inbound or outbound */
+   odp_ipsec_dir_t dir;
+
+   /** IPSEC SA direction dependent parameters */
+   union {
+   /** Inbound specific parameters */
+   struct {
+   /** SA lookup mode */
+   odp_ipsec_lookup_mode_t lookup_mode;
+
+   /** Additional inbound SA lookup parameters. Values are
+   *  considered only in ODP_IPSEC_LOOKUP_DSTADDR_SPI
+   *  lookup mode. */
+   struct {
+   /** Select IP version
+   */
+   odp_ipsec_ip_version_t ip_version;
+
+   /** IP destination address (NETWORK ENDIAN) */
+   void*dst_addr;
+
+   } lookup_param;
+
+   /** Minimum anti-replay window size. Use 0 to disable
+   *  anti-replay service. */
+   uint32_t antireplay_ws;
+
+   /** Classifier destination CoS for resulting packets
+   *
+   *  Successfully decapsulated packets are sent to
+   *  classification through this CoS. Other resulting
+   *  events are sent to 'dest_queue'.
+   *  This field is considered only when 'pipeline' is
+   *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared
+   *  between any pktio interface default CoS. The maximum
+   *  number of different CoS supported is defined by
+   *  IPSEC capability max_cls_cos.
+   */
+   odp_cos_t dest_cos;
+   } inbound;
+
+   /** Outbound specific parameters */
+   struct {
+   /** Parameters for tunne

[lng-odp] [API-NEXTv2] api: ipsec: reorganize odp_ipsec_sa_param_t structure

2017-06-22 Thread Bogdan Pricope
Reorganize odp_ipsec_sa_param_t structure to highlight inbound only and
outbound only members.
To be applied on top of Petri's v3 of 'IPSEC packet event'

v2:
  Set names for inbound only and outbound only struct members

Bogdan Pricope (1):
  api: ipsec: reorganize odp_ipsec_sa_param_t structure based on SA
direction

 include/odp/api/spec/ipsec.h | 114 ---
 1 file changed, 63 insertions(+), 51 deletions(-)

-- 
1.9.1



[lng-odp] [CLOUD-DEV] ddf: examples: add ddf module skeleton and ddf application

2017-06-21 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/Makefile.am |  4 +-
 example/ddf_app/Makefile.am | 10 
 example/ddf_app/odp_ddf_app.c   | 49 +++
 example/ddf_ifs/Makefile.am | 26 ++
 example/ddf_ifs/ddf_ifs.c   | 28 +++
 example/ddf_ifs/ddf_ifs.h   | 18 +++
 example/ddf_ifs/ddf_ifs_api.h   | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.c  | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.h  | 24 +
 example/ddf_ifs/ddf_ifs_devio_direct.c  | 51 +++
 example/ddf_ifs/ddf_ifs_devio_direct.h  | 20 
 example/ddf_ifs/ddf_ifs_driver.c| 69 ++
 example/ddf_ifs/ddf_ifs_driver.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_class.c   | 47 ++
 example/ddf_ifs/ddf_ifs_enumr_class.h   | 20 
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 +
 example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++
 example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 
 example/ddf_ifs/odp.conf|  4 ++
 example/m4/configure.m4 |  2 +
 21 files changed, 624 insertions(+), 1 deletion(-)
 create mode 100644 example/ddf_app/Makefile.am
 create mode 100644 example/ddf_app/odp_ddf_app.c
 create mode 100644 example/ddf_ifs/Makefile.am
 create mode 100644 example/ddf_ifs/ddf_ifs.c
 create mode 100644 example/ddf_ifs/ddf_ifs.h
 create mode 100644 example/ddf_ifs/ddf_ifs_api.h
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.c
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h
 create mode 100644 example/ddf_ifs/odp.conf

diff --git a/example/Makefile.am b/example/Makefile.am
index dfc07b6..b209585 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -8,4 +8,6 @@ SUBDIRS = classifier \
  switch \
  time \
  timer \
- traffic_mgmt
+ traffic_mgmt \
+ ddf_ifs \
+ ddf_app
diff --git a/example/ddf_app/Makefile.am b/example/ddf_app/Makefile.am
new file mode 100644
index 000..e654202
--- /dev/null
+++ b/example/ddf_app/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_ddf_app$(EXEEXT)
+odp_ddf_app_LDFLAGS = $(AM_LDFLAGS) -shared
+odp_ddf_app_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_ddf_app_SOURCES = odp_ddf_app.c
diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c
new file mode 100644
index 000..c2d7abf
--- /dev/null
+++ b/example/ddf_app/odp_ddf_app.c
@@ -0,0 +1,49 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/** enable strtok */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char *argv[])
+{
+   odp_instance_t instance;
+
+   (void)argc;
+   (void)argv;
+
+   EXAMPLE_DBG("Start DDF Application...\n");
+
+   /* Initialize ODP before calling anything else */
+   if (odp_init_global(, NULL, NULL)) {
+   EXAMPLE_ERR("Error: ODP global init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   if (odp_init_local(instance, ODP_THREAD_CONTROL)) {
+   EXAMPLE_ERR("Error: ODP local init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   /* Print ddf objects*/
+   odpdrv_print_all();
+
+   /* Terminate ODP */
+   odp_term_local();
+   odp_term_global(instance);
+
+   EXAMPLE_DBG("Exit DDF Application.\n");
+   return 0;
+}
diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am
new file mode 100644
index 000..b11cf3d
--- /dev/null
+++ b/example/ddf_ifs/Makefile.am
@@ -0,0 +1,26 @@
+LIB   = $(top_builddir)/lib
+
+AM_CPPFLAGS +=  -I$(srcdir) \
+   -I$(top_srcdir)/include \
+   -I$(top_srcdir)/platform/@with_platform@/include \
+   -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@
+
+lib_LTLIBRARIES = $(LIB)/libddf_ifs.la
+
+noinst_HEADERS = \
+$(srcdir)/ddf_ifs.h \
+$(srcdir)/ddf

[lng-odp] [CLOUD-DEV] ddf: examples: ddf module skeleton

2017-06-21 Thread Bogdan Pricope
This patch contains a ddf module skeleton (example) and a ddf model application.
Was designed to highlight (print) DDF operations/steps.

Module is loaded at init_global time through odp configuration file (modules 
section).

Usage:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/odp/lib/.libs

ODP_SYSCONFIG_FILE=/home/odp/example/ddf_ifs/odp.conf 
./example/ddf_app/odp_ddf_app

Bogdan Pricope (1):
  ddf: examples: add ddf module skeleton and ddf application

 example/Makefile.am |  4 +-
 example/ddf_app/Makefile.am | 10 
 example/ddf_app/odp_ddf_app.c   | 49 +++
 example/ddf_ifs/Makefile.am | 26 ++
 example/ddf_ifs/ddf_ifs.c   | 28 +++
 example/ddf_ifs/ddf_ifs.h   | 18 +++
 example/ddf_ifs/ddf_ifs_api.h   | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.c  | 25 ++
 example/ddf_ifs/ddf_ifs_dev_dpdk.h  | 24 +
 example/ddf_ifs/ddf_ifs_devio_direct.c  | 51 +++
 example/ddf_ifs/ddf_ifs_devio_direct.h  | 20 
 example/ddf_ifs/ddf_ifs_driver.c| 69 ++
 example/ddf_ifs/ddf_ifs_driver.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_class.c   | 47 ++
 example/ddf_ifs/ddf_ifs_enumr_class.h   | 20 
 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 +
 example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 
 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++
 example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 
 example/ddf_ifs/odp.conf|  4 ++
 example/m4/configure.m4 |  2 +
 21 files changed, 624 insertions(+), 1 deletion(-)
 create mode 100644 example/ddf_app/Makefile.am
 create mode 100644 example/ddf_app/odp_ddf_app.c
 create mode 100644 example/ddf_ifs/Makefile.am
 create mode 100644 example/ddf_ifs/ddf_ifs.c
 create mode 100644 example/ddf_ifs/ddf_ifs.h
 create mode 100644 example/ddf_ifs/ddf_ifs_api.h
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c
 create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.c
 create mode 100644 example/ddf_ifs/ddf_ifs_driver.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c
 create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h
 create mode 100644 example/ddf_ifs/odp.conf

-- 
1.9.1



Re: [lng-odp] [PATCH 0/6] dpdk pktio: enable hardware checksum support

2017-06-20 Thread Bogdan Pricope
Ping?

On 31 May 2017 at 17:40, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Add HW checksum calculation/validation support for dpdk pktio.
> No UDP/TCP HW checksum calculation/validation support for:
>  - IPv4 fragments
>  - IPv6 packets with extension headers (including fragments)
>
> Bogdan Pricope (6):
>   Initialize pktio configuration structure
>   dpdk: retrieve offload capabilities
>   dpdk: enable per pktio RX IP/UDP/TCP checksum offload
>   dpdk: RX - process checksum validation offload flags
>   dpdk: TX - set checksum calculation offload flags
>   examples: generator: update odp_generator to use HW checksum
> capabilities
>
>  example/generator/odp_generator.c  | 107 ++---
>  platform/linux-generic/odp_packet_io.c |   2 +
>  platform/linux-generic/pktio/dpdk.c| 203 
> -
>  3 files changed, 293 insertions(+), 19 deletions(-)
>
> --
> 1.9.1
>


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

2017-06-20 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 include/odp/api/spec/ipsec.h | 114 ---
 1 file changed, 63 insertions(+), 51 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index e602e4b..08c820e 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -604,8 +604,8 @@ typedef enum odp_ipsec_ip_version_t {
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
-   /** IPSEC SA direction: inbound or outbound */
-   odp_ipsec_dir_t dir;
+   /** SPI value */
+   uint32_t spi;
 
/** IPSEC protocol: ESP or AH */
odp_ipsec_protocol_t proto;
@@ -616,51 +616,12 @@ typedef struct odp_ipsec_sa_param_t {
/** Parameters for crypto and authentication algorithms */
odp_ipsec_crypto_param_t crypto;
 
-   /** Parameters for tunnel mode */
-   odp_ipsec_tunnel_param_t tunnel;
-
-   /** Fragmentation mode */
-   odp_ipsec_frag_mode_t frag_mode;
-
-   /** Various SA option flags */
-   odp_ipsec_sa_opt_t opt;
-
/** SA lifetime parameters */
odp_ipsec_lifetime_t lifetime;
 
-   /** SA lookup mode */
-   odp_ipsec_lookup_mode_t lookup_mode;
-
-   /** Minimum anti-replay window size. Use 0 to disable anti-replay
- * service. */
-   uint32_t antireplay_ws;
-
/** Initial sequence number */
uint64_t seq;
 
-   /** SPI value */
-   uint32_t spi;
-
-   /** Additional inbound SA lookup parameters. Values are considered
-*  only in ODP_IPSEC_LOOKUP_DSTADDR_SPI lookup mode. */
-   struct {
-   /** Select IP version
-*/
-   odp_ipsec_ip_version_t ip_version;
-
-   /** IP destination address (NETWORK ENDIAN) */
-   void*dst_addr;
-
-   } lookup_param;
-
-   /** MTU for outbound IP fragmentation offload
-*
-*  This is the maximum length of IP packets that outbound IPSEC
-*  operations may produce. The value may be updated later with
-*  odp_ipsec_mtu_update().
-*/
-   uint32_t mtu;
-
/** Select pipelined destination for resulting events
 *
 *  Asynchronous and inline modes generate events. Select where
@@ -677,16 +638,67 @@ typedef struct odp_ipsec_sa_param_t {
 */
odp_queue_t dest_queue;
 
-   /** Classifier destination CoS for resulting packets
-*
-*  Successfully decapsulated packets are sent to classification
-*  through this CoS. Other resulting events are sent to 'dest_queue'.
-*  This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS. The maximum number of different CoS supported
-*  is defined by IPSEC capability max_cls_cos.
-*/
-   odp_cos_t dest_cos;
+   /** IPSEC SA direction: inbound or outbound */
+   odp_ipsec_dir_t dir;
+
+   /** IPSEC SA direction dependent parameters */
+   union {
+   /** Inbound specific parameters */
+   struct {
+   /** SA lookup mode */
+   odp_ipsec_lookup_mode_t lookup_mode;
+
+   /** Additional inbound SA lookup parameters. Values are
+   *  considered only in ODP_IPSEC_LOOKUP_DSTADDR_SPI
+   *  lookup mode. */
+   struct {
+   /** Select IP version
+   */
+   odp_ipsec_ip_version_t ip_version;
+
+   /** IP destination address (NETWORK ENDIAN) */
+   void*dst_addr;
+
+   } lookup_param;
+
+   /** Minimum anti-replay window size. Use 0 to disable
+   *  anti-replay service. */
+   uint32_t antireplay_ws;
+
+   /** Classifier destination CoS for resulting packets
+   *
+   *  Successfully decapsulated packets are sent to
+   *  classification through this CoS. Other resulting
+   *  events are sent to 'dest_queue'.
+   *  This field is considered only when 'pipeline' is
+   *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared
+   *  between any pktio interface default CoS. The maximum
+   *  number of different CoS supported is defined by
+   *  IPSEC capability max_cls_cos.
+   */
+   odp_cos_t dest_cos;
+   };
+
+   /** Outbound specific parameters */
+   struct {
+   /** Parameters for tunne

[lng-odp] [API-NEXT] api: ipsec: reorganize odp_ipsec_sa_param_t structure

2017-06-20 Thread Bogdan Pricope
Reorganize odp_ipsec_sa_param_t structure to highlight inbound only and
outbound only members.
To be applied on top of Petri's v3 of 'IPSEC packet event'

Bogdan Pricope (1):
  api: ipsec: reorganize odp_ipsec_sa_param_t structure based on SA
direction

 include/odp/api/spec/ipsec.h | 114 ---
 1 file changed, 63 insertions(+), 51 deletions(-)

-- 
1.9.1



[lng-odp] DDF design considerations

2017-06-16 Thread Bogdan Pricope
Hi,

This doc contains some thoughts on DDF design. Please take a look and
share your comments.

https://docs.google.com/a/linaro.org/document/d/1OJg1Ouj0Fktg_Ng93DqJgNwuWA_d8xyLBQ2izd3GuD8/edit?usp=sharing

/B


Re: [lng-odp] [API-NEXT v2 2/2] timer: allow timer processing to run on worker cores

2017-06-08 Thread Bogdan Pricope
Brian, during yesterday meeting you mentioned about modifying this
patch to call timer processing function (_timer_run()) after fixed (or
dynamically determined) number of loops:
 - If you meant application loops (calls to odp_schedule()), this is
wrong for the reasons presented in my prev. email
 - If you meant scheduler internal loops (calls to do_schedule() from
inside schedule_loop()), this may work.

On 7 June 2017 at 20:02, Brian Brooks <brian.bro...@arm.com> wrote:
> On 06/07 17:39:16, Bogdan Pricope wrote:
>> In OFP we have this use case: N-1 cores are doing packet processing in
>> direct pktin mode; core 0 is doing odp_schedule() to process timers
>> (ARP entries expiration) and maybe other events.
>>
>> To take from this:
>> -  If scheduler + timers are used, may not be use on all cores
>> -  If scheduler + timers are used, odp_schedule() may not be
>> called at the rate of the packets
>>
>>
>> So, is not a good idea to condition timer processing to the number of
>> odp_schedule() calls.
>
> Can you please elaborate on how you reached this conclusion? I did not
> understand.
>
>> On 7 June 2017 at 10:30, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia.com> wrote:
>> >
>> >>
>> >> diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h
>> >> index 154cdf8f..44950893 100644
>> >> --- a/include/odp/api/spec/init.h
>> >> +++ b/include/odp/api/spec/init.h
>> >> @@ -153,6 +153,11 @@ typedef struct odp_init_t {
>> >>   odp_log_func_t log_fn;
>> >>   /** Replacement for the default abort fn */
>> >>   odp_abort_func_t abort_fn;
>> >> + /** Whether the application will ever call odp_schedule() or
>> >> not.
>> >> +
>> >> + Default: true
>> >> + */
>> >> + odp_bool_t use_scheduler;
>> >>  } odp_init_t;
>> >
>> >
>> > This is an API change. It should be in a separate patch and subject should 
>> > be "api: init: ...".
>> >
>> > Anyway, Bill sent already a proposal that is closer what I described 
>> > earlier. Init struct should have odp_feature_t bit field for feature / 
>> > unused_feature selection.
>> >
>> > -Petri


Re: [lng-odp] [API-NEXT v2 2/2] timer: allow timer processing to run on worker cores

2017-06-07 Thread Bogdan Pricope
In OFP we have this use case: N-1 cores are doing packet processing in
direct pktin mode; core 0 is doing odp_schedule() to process timers
(ARP entries expiration) and maybe other events.

To take from this:
-  If scheduler + timers are used, may not be use on all cores
-  If scheduler + timers are used, odp_schedule() may not be
called at the rate of the packets


So, is not a good idea to condition timer processing to the number of
odp_schedule() calls.


On 7 June 2017 at 10:30, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>>
>> diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h
>> index 154cdf8f..44950893 100644
>> --- a/include/odp/api/spec/init.h
>> +++ b/include/odp/api/spec/init.h
>> @@ -153,6 +153,11 @@ typedef struct odp_init_t {
>>   odp_log_func_t log_fn;
>>   /** Replacement for the default abort fn */
>>   odp_abort_func_t abort_fn;
>> + /** Whether the application will ever call odp_schedule() or
>> not.
>> +
>> + Default: true
>> + */
>> + odp_bool_t use_scheduler;
>>  } odp_init_t;
>
>
> This is an API change. It should be in a separate patch and subject should be 
> "api: init: ...".
>
> Anyway, Bill sent already a proposal that is closer what I described earlier. 
> Init struct should have odp_feature_t bit field for feature / unused_feature 
> selection.
>
> -Petri


[lng-odp] [PATCH 6/6] examples: generator: update odp_generator to use HW checksum capabilities

2017-05-31 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 107 --
 1 file changed, 92 insertions(+), 15 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 3ec7d8d..78d568a 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -92,6 +93,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -116,6 +118,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -193,7 +198,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,8 +243,10 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
-   udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum) {
+   udp->chksum = 0;
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   }
 
return pkt;
 }
@@ -252,7 +260,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -274,7 +283,15 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN +
+ODPH_IPV4HDR_LEN);
+   }
 
return pkt;
 }
@@ -343,7 +360,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -368,7 +386,8 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -382,6 +401,13 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN +
+ODPH_IPV4HDR_LEN);
+   }
+
  

[lng-odp] [PATCH 5/6] dpdk: TX - set checksum calculation offload flags

2017-05-31 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 platform/linux-generic/pktio/dpdk.c | 105 ++--
 1 file changed, 102 insertions(+), 3 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 58e6db0..b721bf6 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -27,6 +27,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 static int disable_pktio; /** !0 this pktio disabled, 0 enabled */
@@ -772,6 +776,41 @@ fail:
return (i > 0 ? i : -1);
 }
 
+static inline int packet_parse(void *l3_hdr, uint8_t *l3_proto_v4,
+  uint8_t *l4_proto)
+{
+   uint8_t l3_proto_ver = _ODP_IPV4HDR_VER(*(uint8_t *)l3_hdr);
+
+   if (l3_proto_ver == _ODP_IPV4) {
+   struct ipv4_hdr *ip = (struct ipv4_hdr *)l3_hdr;
+
+   *l3_proto_v4 = 1;
+   if (!rte_ipv4_frag_pkt_is_fragmented(ip))
+   *l4_proto = ip->next_proto_id;
+   else
+   *l4_proto = 0;
+
+   return 0;
+   } else if (l3_proto_ver == _ODP_IPV6) {
+   struct ipv6_hdr *ipv6 = (struct ipv6_hdr *)l3_hdr;
+
+   *l3_proto_v4 = 0;
+   *l4_proto = ipv6->proto;
+   return 0;
+   }
+
+   return -1;
+}
+
+static inline uint16_t phdr_csum(int ipv4, void *l3_hdr,
+uint64_t ol_flags)
+{
+   if (ipv4)
+   return rte_ipv4_phdr_cksum(l3_hdr, ol_flags);
+   else /*ipv6*/
+   return rte_ipv6_phdr_cksum(l3_hdr, ol_flags);
+}
+
 static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
  struct rte_mbuf *mbuf_table[],
  const odp_packet_t pkt_table[], uint16_t num)
@@ -779,15 +818,30 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
pkt_dpdk_t *pkt_dpdk = _entry->s.pkt_dpdk;
int i, j;
char *data;
+   odp_packet_t pkt;
uint16_t pkt_len;
+   packet_parser_t *pkt_p;
+   struct rte_mbuf *mbuf;
+   void *l3_hdr, *l4_hdr;
+   odp_bool_t ipv4_chksum_cfg, udp_chksum_cfg, tcp_chksum_cfg;
+   odp_bool_t ipv4_chksum_pkt, udp_chksum_pkt, tcp_chksum_pkt;
+   uint8_t l3_proto_v4, l4_proto;
 
if (odp_unlikely((rte_pktmbuf_alloc_bulk(pkt_dpdk->pkt_pool,
 mbuf_table, num {
ODP_ERR("Failed to alloc mbuf\n");
return 0;
}
+
+   ipv4_chksum_cfg = pktio_entry->s.config.pktout.bit.ipv4_chksum;
+   udp_chksum_cfg = pktio_entry->s.config.pktout.bit.udp_chksum;
+   tcp_chksum_cfg = pktio_entry->s.config.pktout.bit.tcp_chksum;
+
for (i = 0; i < num; i++) {
-   pkt_len = _odp_packet_len(pkt_table[i]);
+   mbuf = mbuf_table[i];
+   pkt = pkt_table[i];
+   pkt_len = _odp_packet_len(pkt);
+   pkt_p = _packet_hdr(pkt)->p;
 
if (pkt_len > pkt_dpdk->mtu) {
if (i == 0)
@@ -796,9 +850,54 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
}
 
/* Packet always fits in mbuf */
-   data = rte_pktmbuf_append(mbuf_table[i], pkt_len);
+   data = rte_pktmbuf_append(mbuf, pkt_len);
+
+   odp_packet_copy_to_mem(pkt, 0, pkt_len, data);
+
+   if (!pktio_entry->s.config.pktout.all_bits)
+   continue;
+
+   l3_hdr = (void *)(data + pkt_p->l3_offset);
+
+   if (packet_parse(l3_hdr, _proto_v4, _proto))
+   continue;
+
+   ipv4_chksum_pkt = ipv4_chksum_cfg && l3_proto_v4;
+   udp_chksum_pkt = udp_chksum_cfg &&
+   (l4_proto == _ODP_IPPROTO_UDP);
+   tcp_chksum_pkt = tcp_chksum_cfg &&
+   (l4_proto == _ODP_IPPROTO_TCP);
+
+   if (!ipv4_chksum_pkt && !udp_chksum_pkt && !tcp_chksum_pkt)
+   continue;
+
+   mbuf->l2_len = pkt_p->l3_offset - pkt_p->l2_offset;
+   mbuf->l3_len = pkt_p->l4_offset - pkt_p->l3_offset;
 
-   odp_packet_copy_to_mem(pkt_table[i], 0, pkt_len, data);
+   if (l3_proto_v4)
+   mbuf->ol_flags = PKT_TX_IPV4;
+   else
+   mbuf->ol_flags = PKT_TX_IPV6;
+
+   if (ipv4_chksum_pkt) {
+   mbuf->ol_flags |=  PKT_TX_IP_CKSUM;
+
+   ((struct ipv4_hdr *)l3_hdr)->hdr_checksum = 0;
+   }
+
+   l4_hdr = (void *)(data + pkt_p->l4_offset);
+
+   if (udp_chksum_p

[lng-odp] [PATCH 1/6] Initialize pktio configuration structure

2017-05-31 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 platform/linux-generic/odp_packet_io.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index 50a000e..dc24ee9 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -150,6 +150,8 @@ static void init_pktio_entry(pktio_entry_t *entry)
init_out_queues(entry);
 
pktio_classifier_init(entry);
+
+   odp_pktio_config_init(>s.config);
 }
 
 static odp_pktio_t alloc_lock_pktio_entry(void)
-- 
1.9.1



[lng-odp] [PATCH 0/6] dpdk pktio: enable hardware checksum support

2017-05-31 Thread Bogdan Pricope
Add HW checksum calculation/validation support for dpdk pktio.
No UDP/TCP HW checksum calculation/validation support for:
 - IPv4 fragments
 - IPv6 packets with extension headers (including fragments)

Bogdan Pricope (6):
  Initialize pktio configuration structure
  dpdk: retrieve offload capabilities
  dpdk: enable per pktio RX IP/UDP/TCP checksum offload
  dpdk: RX - process checksum validation offload flags
  dpdk: TX - set checksum calculation offload flags
  examples: generator: update odp_generator to use HW checksum
capabilities

 example/generator/odp_generator.c  | 107 ++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 203 -
 3 files changed, 293 insertions(+), 19 deletions(-)

-- 
1.9.1



[lng-odp] [RFCv6] dpdk: enable hardware checksum support

2017-05-30 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 100 ++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 190 -
 3 files changed, 273 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 3ec7d8d..1cd3e29 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -92,6 +93,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -116,6 +118,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -193,7 +198,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,8 +243,10 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
-   udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum) {
+   udp->chksum = 0;
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   }
 
return pkt;
 }
@@ -252,7 +260,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -274,7 +283,14 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   }
 
return pkt;
 }
@@ -343,7 +359,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -368,7 +385,8 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -382,6 +400,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODP

[lng-odp] [RFCv6] dpdk pktio: enable hardware checksum support

2017-05-30 Thread Bogdan Pricope
v6:
 - TX - change packet parser to use odp macros
 - TX/RX - reduce impact on 'no HW csum' usecase
 - RX - fix mbuf leak on packets with csum error
v5:
 - TX - parse packet to get l3 and l4 protocols
 - RX - update ptype checking for IPv4
v4:
 - TX - disable L4 checksum calculation for fragments
 - TX - fix L3 offload flags
 - RX - fix ptype checking
v3:
 - RX - enable offload only for supported ptypes
 - TX - no offload is odp packet does not have correct protocol flags
 - TX - use packet header flags instead of public API
v2:
 - add drop_XXX_err support
 - use mbuf packet type flags in interpreting offload results

Bogdan Pricope (1):
  dpdk: enable hardware checksum support

 example/generator/odp_generator.c  | 100 ++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 190 -
 3 files changed, 273 insertions(+), 19 deletions(-)

-- 
1.9.1



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

2017-05-30 Thread Bogdan Pricope
On 29 May 2017 at 15:08, Elo, Matias (Nokia - FI/Espoo)
 wrote:
> Hi Bogdan,
>
> I still think rx checksum calculation should be combined with packet parsing 
> but below are some comments regarding this rfc code.

This RFC is for master branch: some of the APIs you need for optimized
parser or csum override are not there (yet) but in api-next. Also, I
am considering putting this in odp-dpdk instead of odp-linux since it
does not require API changes and odp-linux is not relevant for
performance runs.

It seams, with your changes you are favoring "non HW csum" case - this
should be the corner case. ODP is meant for performance and one would
select a board with HW capabilities and would expect maximum
performance for this case.
Anyway, I'll do this changes and send the (final) RFCv6. Speak now or
forever hold your peace.

/B

>
> -Matias
>
>>
>> static int dpdk_open(odp_pktio_t id ODP_UNUSED,
>> @@ -605,9 +666,11 @@ static inline int mbuf_to_pkt(pktio_entry_t 
>> *pktio_entry,
>>   int nb_pkts = 0;
>>   int alloc_len, num;
>>   odp_pool_t pool = pktio_entry->s.pkt_dpdk.pool;
>> + odp_pktin_config_opt_t *pktin_cfg;
>>
>>   /* Allocate maximum sized packets */
>>   alloc_len = pktio_entry->s.pkt_dpdk.data_room;
>> + pktin_cfg = _entry->s.config.pktin;
>>
>>   num = packet_alloc_multi(pool, alloc_len, pkt_table, mbuf_num);
>>   if (num != mbuf_num) {
>> @@ -658,6 +721,34 @@ static inline int mbuf_to_pkt(pktio_entry_t 
>> *pktio_entry,
>>   if (mbuf->ol_flags & PKT_RX_RSS_HASH)
>>   odp_packet_flow_hash_set(pkt, mbuf->hash.rss);
>>
>> + if ((mbuf->packet_type & RTE_PTYPE_L3_IPV4) && /* covers IPv4, 
>> IPv4_EXT, IPv4_EXT_UKN */
>> + pktin_cfg->bit.ipv4_chksum &&
>> + mbuf->ol_flags & PKT_RX_IP_CKSUM_BAD) {
>
> pktin_cfg->bit.ipv4_chksum should be checked first.
>
>> + if (pktin_cfg->bit.drop_ipv4_err) {
>> + odp_packet_free(pkt);
>> + continue;
>
> The mbuf is never freed.
>
>> + } else
>> + pkt_hdr->p.error_flags.ip_err = 1;
>> + }
>> +
>> + if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) == 
>> RTE_PTYPE_L4_UDP &&
>> + pktin_cfg->bit.udp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>
> pktin_cfg->bit.udp_chksum first.
>
>> + if (pktin_cfg->bit.drop_udp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>
> The mbuf is never freed.
>
>> + } else
>> + pkt_hdr->p.error_flags.udp_err = 1;
>> + } else if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) == 
>> RTE_PTYPE_L4_TCP &&
>> + pktin_cfg->bit.tcp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>
> pktin_cfg->bit.tcp_chksum first.
>
>> + if (pktin_cfg->bit.drop_tcp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>
> The mbuf is never freed.
>
>>
>> +#define IP_VERSION   0x40
>> +#define IP6_VERSION  0x60
>> +
>> +static int packet_parse(void *l3_hdr, uint8_t *l3_proto_v4, uint8_t 
>> *l4_proto)
>> +{
>> + uint8_t l3_proto = (*(uint8_t *)l3_hdr & 0xf0);
>> +
>
> You can use _ODP_IPV4HDR_VER(), _ODP_IPV4, _ODP_IPV6 here.
>
>> @@ -700,9 +841,45 @@ static inline int pkt_to_mbuf(pktio_entry_t 
>> *pktio_entry,
>>   }
>>
>>   /* Packet always fits in mbuf */
>> - data = rte_pktmbuf_append(mbuf_table[i], pkt_len);
>> + data = rte_pktmbuf_append(mbuf, pkt_len);
>> +
>> + odp_packet_copy_to_mem(pkt, 0, pkt_len, data);
>
> You can check pktio_entry->s.config.pktout.all_bits here and do continue if 
> no checksums
> are enabled.
>
>> + ipv4_chksum_pkt = l3_proto_v4 && ipv4_chksum_cfg;
>> + udp_chksum_pkt = (l4_proto == IPPROTO_UDP) && udp_chksum_cfg;
>> + tcp_chksum_pkt = (l4_proto == IPPROTO_TCP) && tcp_chksum_cfg;
>
> Config checks first.
>


[lng-odp] [RFCv5] dpdk: enable hardware checksum support

2017-05-26 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 100 +++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 185 -
 3 files changed, 268 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 3ec7d8d..1cd3e29 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -92,6 +93,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -116,6 +118,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -193,7 +198,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,8 +243,10 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
-   udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum) {
+   udp->chksum = 0;
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   }
 
return pkt;
 }
@@ -252,7 +260,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -274,7 +283,14 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   }
 
return pkt;
 }
@@ -343,7 +359,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -368,7 +385,8 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -382,6 +400,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODP

[lng-odp] [RFCv5] dpdk pktio: enable hardware checksum support

2017-05-26 Thread Bogdan Pricope
v5:
 - TX - parse packet to get l3 and l4 protocols
 - RX - update ptype checking for IPv4
v4:
 - TX - disable L4 checksum calculation for fragments
 - TX - fix L3 offload flags
 - RX - fix ptype checking
v3:
 - RX - enable offload only for supported ptypes
 - TX - no offload is odp packet does not have correct protocol flags
 - TX - use packet header flags instead of public API
v2:
 - add drop_XXX_err support
 - use mbuf packet type flags in interpreting offload results

Bogdan Pricope (1):
  dpdk: enable hardware checksum support

 example/generator/odp_generator.c  | 100 +++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 185 -
 3 files changed, 268 insertions(+), 19 deletions(-)

-- 
1.9.1



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

2017-05-24 Thread Bogdan Pricope
Hi Matias,

Using ptypes reported by dpdk in parser was intended for another patch
(next work after csum).

I guess your test is a degradation test (due to new ifs) and you did
not enabled csum offloads/ set flags on packets.

What will be interesting to see:
 - in a generation or termination test (UDP), what will be
degradation/gain with csum offload enabled
 - how degradation/gain is changing with bigger packets (256 bytes vs 64 bytes)

BR,
Bogdan


On 24 May 2017 at 10:53, Elo, Matias (Nokia - FI/Espoo)
 wrote:
> Hi Bogdan,
>
> I ran a quick test run with the patch and the overhead seems to be
> surprisingly small at least on a Xeon cpu (E5-2697v3). However, I would
> still suggest making some changes to the code. More below.
>
> -Matias
>
>
>
>>
>> @@ -605,9 +663,11 @@ static inline int mbuf_to_pkt(pktio_entry_t
>> *pktio_entry,
>>int nb_pkts = 0;
>>int alloc_len, num;
>>odp_pool_t pool = pktio_entry->s.pkt_dpdk.pool;
>> + odp_pktin_config_opt_t *pktin_cfg;
>>
>>/* Allocate maximum sized packets */
>>alloc_len = pktio_entry->s.pkt_dpdk.data_room;
>> + pktin_cfg = _entry->s.config.pktin;
>>
>>num = packet_alloc_multi(pool, alloc_len, pkt_table, mbuf_num);
>>if (num != mbuf_num) {
>> @@ -658,6 +718,34 @@ static inline int mbuf_to_pkt(pktio_entry_t
>> *pktio_entry,
>>if (mbuf->ol_flags & PKT_RX_RSS_HASH)
>>odp_packet_flow_hash_set(pkt, mbuf->hash.rss);
>>
>> + if ((mbuf->packet_type & RTE_PTYPE_L3_MASK) ==
>> RTE_PTYPE_L3_IPV4 &&
>> + pktin_cfg->bit.ipv4_chksum &&
>> + mbuf->ol_flags & PKT_RX_IP_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_ipv4_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.ip_err = 1;
>> + }
>> +
>> + if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) ==
>> RTE_PTYPE_L4_UDP &&
>> + pktin_cfg->bit.udp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_udp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.udp_err = 1;
>> + } else if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) ==
>> RTE_PTYPE_L4_TCP &&
>> + pktin_cfg->bit.tcp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_tcp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.tcp_err = 1;
>> + }
>> +
>
> Instead of doing packet parsing and checksum validation separately I would
> do both in one function. The api-next pktio code (should be merged to
> master) has a new configuration option 'odp_pktio_config_t.parser.layer',
> which selects the parsing level. packet_parse_layer() function is then used
> to parse the received packet up to the selected level.
>
> So, instead of of calling packet_parse_layer() in dpdk pktio I would add a
> new dpdk specific implementation of this function. This way we can exploit
> all dpdk packet parsing features in addition to the checksum calculations.
> Also, by doing this you can remove most of the if() calls above. Enabling a
> higher protocol layer checksum calculation than the selected parsing level
> would be a user error (e.g. ODP_PKTIO_PARSER_LAYER_L2 and TCP checksum
> enabled).
>
>


Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-05-24 Thread Bogdan Pricope
Hi Yi,

As I said in my reply, the sender is also the interpreter of the data.
The peer must only send the payload unmodified in echo reply - it is
not relevant if it understands or not the payload (it is opaque data
for peer): you can ping la Ubuntu or FreeBSD machine... don't expect
them to understand the payload but only to send it back unmodified.

Best regards,
Bogdan

On 24 May 2017 at 11:03, Yi He <yi...@linaro.org> wrote:
> O, sorry Bogdan missed your reply,
>
> I saw the time value in ICMP message was filled(sending) by "memcpy(tval_d,
> ..., sizeof(uint64_t));" and processed(receiving) as "memcpy(, ...,
> sizeof(uint64_t));"
>
> If the sending peer is little endian and the receiving peer is big endian I
> think it will cause wrong interpretation, right?
>
> Best Regards, Yi
>
> On 24 May 2017 at 15:48, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>>
>> Ping.
>>
>> On 3 May 2017 at 11:45, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>> > Hi Yi,
>> >
>> > I disagree:  bytes sent in Data field of Echo request are opaque and
>> > have no meaning for any other entity then ‘me’ (the sender of echo
>> > request / receiver of echo reply).
>> >
>> > The only obligation of the receiver of echo request, as stated by RFC
>> > 792 is:
>> > “The data received in the echo message must be returned in the echo
>> > reply message.”
>> >
>> > There is no standardization on what should be there (some even using
>> > it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
>> > whatever sender wants –endianness transformations are not useful in
>> > this case.
>> >
>> > BR,
>> > Bogdan
>> >
>> > On 19 April 2017 at 06:08, Yi He <yi...@linaro.org> wrote:
>> >> Hi, Bogdan
>> >>
>> >> Consider endianness for this uint64_t time value carried in ICMP
>> >> packets,
>> >> need htonl and ntohl here.
>> >>
>> >> Best Regards, Yi
>> >>
>> >>
>> >>
>> >> On 11 April 2017 at 19:31, Bogdan Pricope <bogdan.pric...@linaro.org>
>> >> wrote:
>> >>>
>> >>> Ping!
>> >>>
>> >>>
>> >>> On 3 April 2017 at 13:00, Bogdan Pricope <bogdan.pric...@linaro.org>
>> >>> wrote:
>> >>> > Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
>> >>> > ---
>> >>> >  example/generator/odp_generator.c | 89
>> >>> > ++-
>> >>> >  1 file changed, 41 insertions(+), 48 deletions(-)
>> >>> >
>> >>> > diff --git a/example/generator/odp_generator.c
>> >>> > b/example/generator/odp_generator.c
>> >>> > index 95fb543..9c49d94 100644
>> >>> > --- a/example/generator/odp_generator.c
>> >>> > +++ b/example/generator/odp_generator.c
>> >>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
>> >>> > appl_args_t *appl_args);
>> >>> >  static void print_info(char *progname, appl_args_t *appl_args);
>> >>> >  static void usage(char *progname);
>> >>> >  static int scan_ip(char *buf, unsigned int *paddr);
>> >>> > -static void tv_sub(struct timeval *recvtime, struct timeval
>> >>> > *sendtime);
>> >>> >  static void print_global_stats(int num_workers);
>> >>> >
>> >>> >  /**
>> >>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
>> >>> > pool,
>> >>> > odp_packet_t pkt_ref)
>> >>> > char *buf;
>> >>> > odph_ipv4hdr_t *ip;
>> >>> > odph_icmphdr_t *icmp;
>> >>> > -   struct timeval tval;
>> >>> > +   uint64_t tval;
>> >>> > uint8_t *tval_d;
>> >>> > unsigned short seq;
>> >>> >
>> >>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
>> >>> > pool,
>> >>> > odp_packet_t pkt_ref)
>> >>> > /* icmp */
>> >>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
>> >>> > ODPH_IPV4HDR_LEN);
>> >>> > icmp->un.echo.sequence = ip->id;
>> >>> > +
>> &

Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-05-24 Thread Bogdan Pricope
Ping.

On 3 May 2017 at 11:45, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Hi Yi,
>
> I disagree:  bytes sent in Data field of Echo request are opaque and
> have no meaning for any other entity then ‘me’ (the sender of echo
> request / receiver of echo reply).
>
> The only obligation of the receiver of echo request, as stated by RFC 792 is:
> “The data received in the echo message must be returned in the echo
> reply message.”
>
> There is no standardization on what should be there (some even using
> it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
> whatever sender wants –endianness transformations are not useful in
> this case.
>
> BR,
> Bogdan
>
> On 19 April 2017 at 06:08, Yi He <yi...@linaro.org> wrote:
>> Hi, Bogdan
>>
>> Consider endianness for this uint64_t time value carried in ICMP packets,
>> need htonl and ntohl here.
>>
>> Best Regards, Yi
>>
>>
>>
>> On 11 April 2017 at 19:31, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>>>
>>> Ping!
>>>
>>>
>>> On 3 April 2017 at 13:00, Bogdan Pricope <bogdan.pric...@linaro.org>
>>> wrote:
>>> > Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
>>> > ---
>>> >  example/generator/odp_generator.c | 89
>>> > ++-
>>> >  1 file changed, 41 insertions(+), 48 deletions(-)
>>> >
>>> > diff --git a/example/generator/odp_generator.c
>>> > b/example/generator/odp_generator.c
>>> > index 95fb543..9c49d94 100644
>>> > --- a/example/generator/odp_generator.c
>>> > +++ b/example/generator/odp_generator.c
>>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
>>> > appl_args_t *appl_args);
>>> >  static void print_info(char *progname, appl_args_t *appl_args);
>>> >  static void usage(char *progname);
>>> >  static int scan_ip(char *buf, unsigned int *paddr);
>>> > -static void tv_sub(struct timeval *recvtime, struct timeval *sendtime);
>>> >  static void print_global_stats(int num_workers);
>>> >
>>> >  /**
>>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>>> > odp_packet_t pkt_ref)
>>> > char *buf;
>>> > odph_ipv4hdr_t *ip;
>>> > odph_icmphdr_t *icmp;
>>> > -   struct timeval tval;
>>> > +   uint64_t tval;
>>> > uint8_t *tval_d;
>>> > unsigned short seq;
>>> >
>>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>>> > odp_packet_t pkt_ref)
>>> > /* icmp */
>>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
>>> > ODPH_IPV4HDR_LEN);
>>> > icmp->un.echo.sequence = ip->id;
>>> > +
>>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN +
>>> >   ODPH_ICMPHDR_LEN);
>>> > -   /* TODO This should be changed to use an
>>> > -* ODP timer API once one exists. */
>>> > -   gettimeofday(, NULL);
>>> > -   memcpy(tval_d, , sizeof(struct timeval));
>>> > +   tval = odp_time_to_ns(odp_time_local());
>>> > +   memcpy(tval_d, , sizeof(uint64_t));
>>> > +
>>> > icmp->chksum = 0;
>>> > icmp->chksum = odph_chksum(icmp, args->appl.payload +
>>> > ODPH_ICMPHDR_LEN);
>>> >
>>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
>>> >  }
>>> >
>>> >  /**
>>> > + * Process icmp packets
>>> > + *
>>> > + * @param  icmp icmp header address
>>> > + * @param  msg output buffer
>>> > + */
>>> > +
>>> > +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
>>> > +{
>>> > +   uint64_t trecv;
>>> > +   uint64_t tsend;
>>> > +   uint64_t rtt_ms, rtt_us;
>>> > +
>>> > +   msg[0] = 0;
>>> > +
>>> > +   if (icmp->type == ICMP_ECHOREPLY) {
>>> > +   odp_atomic_inc_u64();
>>> > +
>>> > +   memcpy(, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
>>> > +  sizeof(uint64_t));
>>> > +   trecv = odp_time_to_ns(odp_time_

Re: [lng-odp] Summary of Expiration Discussion

2017-05-24 Thread Bogdan Pricope
This ‘status_queue’ looks fine to me.

/Bogdan

On 24 May 2017 at 02:20, Bill Fischofer  wrote:
> This is a quick summary of the expiration discussion held during
> Monday's ARCH call.
>
> The current odp_ipsec_capability_t defines two fields:
>
> /** Soft expiry limit in seconds support
> *
> *  0: Limit is not supported
> *  1: Limit is supported
> */
> uint8_t soft_limit_sec;
>
> /** Hard expiry limit in seconds support
> *
> *  0: Limit is not supported
> *  1: Limit is supported
> */
> uint8_t hard_limit_sec;
>
> Presumably the uint8_t's here should be changed to odp_support_t's, or
> removed entirely.  On the odp_ipsec_sa_create() call passes an
> odp_ipsec_param_t struct and one of the sub-structures in that is an
> odp_ipsec_lifetime_t struct that specifies hard and soft expiry limits
> for bytes, packets, and or time (in seconds).  These lifetimes are
> defined by RFC 4301 which states (Section 4.4.2.1):
>
> The following data items MUST be in the SAD:
> ...
>
> - Lifetime of this SA: a time interval after which an SA must be
>   replaced with a new SA (and new SPI) or terminated, plus an
>   indication of which of these actions should occur.  This may be
>   expressed as a time or byte count, or a simultaneous use of both
>   with the first lifetime to expire taking precedence.  A compliant
>   implementation MUST support both types of lifetimes, and MUST
>   support a simultaneous use of both.
>...
>
>   Note: The details of how to handle the refreshing
>   of keys when SAs expire is a local matter.  However, one
>   reasonable approach is:
>
>  (a) If byte count is used, then the implementation SHOULD count the
>  number of bytes to which the IPsec cryptographic algorithm is
>  applied.  For ESP, this is the encryption algorithm (including
>  Null encryption) and for AH, this is the authentication
>  algorithm.  This includes pad bytes, etc.  Note that
>  implementations MUST be able to handle having the counters at
>  the ends of an SA get out of synch, e.g., because of packet
>  loss or because the implementations at each end of the SA
>  aren't doing things the same way.
>
>  (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
>  warns the implementation to initiate action such as setting up
>  a replacement SA, and a hard lifetime when the current SA ends
>  and is destroyed.
>
>  (c) If the entire packet does not get delivered during the SA's
>  lifetime, the packet SHOULD be discarded.
>
> With this background, it's clear that should we choose to remove
> time-based expiration from the ODP IPsec API spec we would have an
> incomplete IPsec specification that would require any ODP
> implementation that wishes to be IPsec compliant to "fill in" the spec
> on its own. That would not be good.  Note also that the RFC says
> nothing about counting packets, only bytes, so perhaps we shouldn't be
> offering packet counts?
>
> Given that we want to keep these, the question is then how are they to
> be handled? The argument I would make is that these are control
> signals as they indicate that the control plane should begin rekeying
> on an SA (soft expiration) or that an SA's lifetime has ended (hard
> expiration). As such they should be odp_ipsec_status_t events, which
> seems to be what IPsec users like OFP would prefer.
>
> Currently the odp_ipsec_param_t includes  the fields:
>
> /** Destination queue for IPSEC events
> *
> *  Operations in asynchronous or inline mode enqueue resulting events
> *  into this queue.
> */
> odp_queue_t dest_queue;
>
> /** Classifier destination CoS for IPSEC result events
> *
> *  Result events for successfully decapsulated packets are sent to
> *  classification through this CoS. Other result events are sent to
> *  'dest_queue'. This field is considered only when 'pipeline' is
> *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
> *  interface default CoS.
> */
> odp_cos_t dest_cos;
>
> But perhaps this is too coarse. Having a dest_cos makes sense for
> PIPELINE_CLS output but the current dest_queue is used for both
> odp_ipsec_result_t and odp_ipsec_status_t events, which inherently
> have different "consumers". So might it make more sense to split this
> into:
>
> /**
> * Output queue for IPSEC results
> *
> * Operations in asynchronous or inline mode enqueue result events are placed
> * onto this queue.
> */
> odp_queue_t result_queue;
>
> /**
> * Output queue for IPSEC status
> *
> * Status events relating to this SA are placed onto this queue.
> */
> odp_queue_t status_queue;
>
> This would also solve the "sync mode" problem that Dmitry mentioned.
> An application that only intends to use IPsec lookaside operations and
> then only in sync mode may set result_queue to ODP_QUEUE_INVALID.
> However, if it wishes to specify a lifetime associated 

[lng-odp] [RFCv4] dpdk: enable hardware checksum support

2017-05-22 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 102 ++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 161 -
 3 files changed, 246 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 79efe5b..d68a31f 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -92,6 +93,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -116,6 +118,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -194,7 +199,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -239,7 +245,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum)
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
 
return pkt;
 }
@@ -253,7 +260,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -275,7 +283,17 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_has_ipv4_set(pkt, 1);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   odp_packet_has_udp_set(pkt, 1);
+   }
 
return pkt;
 }
@@ -344,7 +362,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -369,7 +388,9 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -383,6 +404,13 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   o

[lng-odp] [RFCv4] dpdk pktio: enable hardware checksum support

2017-05-22 Thread Bogdan Pricope
v4:
 - TX - disable L4 checksum calculation for fragments
 - TX - fix L3 offload flags
 - RX - fix ptype checking
v3:
 - RX - enable offload only for supported ptypes
 - TX - no offload is odp packet does not have correct protocol flags
 - TX - use packet header flags instead of public API
v2:
 - add drop_XXX_err support
 - use mbuf packet type flags in interpreting offload results

Bogdan Pricope (1):
  dpdk: enable hardware checksum support

 example/generator/odp_generator.c  | 102 ++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 161 -
 3 files changed, 246 insertions(+), 19 deletions(-)

-- 
1.9.1



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

2017-05-22 Thread Bogdan Pricope
Hi,

Preconditions for HW checksum calculation and some thoughts on
fragmentation case:

Preconditions for IPv4 checksum calculation:
-  HW support for IPv4 checksum calculation &  configured
-  ip->csum  set to 0
-  L2, L3, L4 offsets set
-  IPv4 flag set (odp_packet_has_ipv4_set())

Preconditions for IPv4 checksum validation:
-  HW support for IPv4 checksum validation &  configured
-  Packet type (ptype) support for IPv4

Preconditions for UDP/TCP checksum calculation:
-  HW support for UDP/TCP checksum calculation &  configured
-  L2, L3, L4 offsets set
-  IPv4/IPv6 flags set
-  udp/tcp flags set

Preconditions for UDP/TCP checksum validation:
-  HW support for UDP/TCP checksum validation &  configured
-  Packet type (ptype) support for UDP and TCP

Fragmentation case (UDP/TCP checksum):
TX:
-  Application must calculate UDP/TCP checksum for (to be)
fragmented packet (HW will not calculate it).
-  Application must either set ‘ipfrag’ flag on the packet or
remove ‘upd’ / ‘tcp’ flags

RX:
-  Ideally, dpdk will report ‘RTE_PTYPE_L4_FRAG’ ptype for
received fragmented packet, but is not always supported. In my case,
it is just not reporting packet as UDP or TCP if it is a fragment
-  Application must validate UDP/TCP checksum on reassembled
packet (HW will not validate it)

/Bogdan

On 18 May 2017 at 11:51, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> v3:
>  - RX - enable offload only for supported ptypes
>  - TX - no offload is odp packet does not have correct protocol flags
>  - TX - use packet header flags instead of public API
> v2:
>  - add drop_XXX_err support
>  - use mbuf packet type flags in interpreting offload results
>
> Bogdan Pricope (1):
>   dpdk: enable hardware checksum support
>
>  example/generator/odp_generator.c  | 102 +++---
>  platform/linux-generic/odp_packet_io.c |   2 +
>  platform/linux-generic/pktio/dpdk.c| 150 
> +++--
>  3 files changed, 235 insertions(+), 19 deletions(-)
>
> --
> 1.9.1
>


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

2017-05-19 Thread Bogdan Pricope
Hi Janne,

There is no undefined behavior: if HW csum is NOT calculated (not
supported by HW OR not configured by application OR override “NOT
insert”) then packet will not be modified (packet will be sent with
the value set by the application).

“HW Supported” = what dpdk reports as HW capabilities (odp_pktio_capability())
“Configured” = what is configured by application with
odp_pktio_config(). This is a subset of what is “HW Supported”.


Behavior:

1. Override not set (default) => depends on „Configured”

2. Override set: do not insert checksum => HW csum NOT calculated

3. Override set: insert checksum => depends on “HW Supported”

BR,
Bogdan


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

2017-05-18 Thread Bogdan Pricope
Hi,

What is the status of this patch?

Can we assume this logic?

HW Supported   & configured  & override insert
 => HW calculation
HW Supported   & configured  & override NOT insert  =>
NO HW calculation
HW Supported   & NOT configured  & override insert  =>
HW calculation
HW Supported   & NOT configured  & override NOT insert  => NO
HW calculation
HW Not Supported
   => NO HW calculation

On 3 April 2017 at 15:43, Bala Manoharan  wrote:
> Reviewed-by: Balasubramanian Manoharan 
>
>
> On 28 March 2017 at 16:37, Petri Savolainen  
> wrote:
>> Checksum insertion has pktio interface level configuration
>> options. Per packet override is needed for example when
>> L4 checksumming is enabled and application forwards packets.
>> Forwarded packets need to maintain original, end-to-end checksum
>> value.
>>
>> Signed-off-by: Petri Savolainen 
>> ---
>>  include/odp/api/spec/packet.h | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/include/odp/api/spec/packet.h b/include/odp/api/spec/packet.h
>> index 92c35ae..5439f23 100644
>> --- a/include/odp/api/spec/packet.h
>> +++ b/include/odp/api/spec/packet.h
>> @@ -1366,6 +1366,32 @@ uint32_t odp_packet_l4_offset(odp_packet_t pkt);
>>  int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t offset);
>>
>>  /**
>> + * Layer 3 checksum insertion override
>> + *
>> + * Override checksum insertion configuration per packet. This per packet 
>> setting
>> + * overrides a higher level configuration for checksum insertion into a L3
>> + * header during packet output processing.
>> + *
>> + * @param pkt Packet handle
>> + * @param l3  0: do not insert L3 checksum
>> + *1: insert L3 checksum
>> + */
>> +void odp_packet_l3_chksum_insert(odp_packet_t pkt, int l3);
>> +
>> +/**
>> + * Layer 4 checksum insertion override
>> + *
>> + * Override checksum insertion configuration per packet. This per packet 
>> setting
>> + * overrides a higher level configuration for checksum insertion into a L4
>> + * header during packet output processing.
>> + *
>> + * @param pkt Packet handle
>> + * @param l4  0: do not insert L4 checksum
>> + *1: insert L4 checksum
>> + */
>> +void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4);
>> +
>> +/**
>>   * Packet flow hash value
>>   *
>>   * Returns the hash generated from the packet header. Use
>> --
>> 2.8.1
>>


Re: [lng-odp] [PATCHv2] examples: generator: UDP ports configuration

2017-05-18 Thread Bogdan Pricope
Ping?

On 3 May 2017 at 10:42, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  example/generator/odp_generator.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index ede1cdf..79efe5b 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -64,6 +64,8 @@ typedef struct {
> odph_ethaddr_t dstmac;  /**< dest mac addr */
> unsigned int srcip; /**< src ip addr */
> unsigned int dstip; /**< dest ip addr */
> +   uint16_t srcport;   /**< src udp port */
> +   uint16_t dstport;   /**< dest udp port */
> int mode;   /**< work mode */
> int number; /**< packets number to be sent */
> int payload;/**< data len */
> @@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
> odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> odp_packet_has_udp_set(pkt, 1);
> udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> -   udp->src_port = 0;
> -   udp->dst_port = 0;
> +   udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
> +   udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
> udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
> udp->chksum = 0;
> udp->chksum = odph_ipv4_udp_chksum(pkt);
> @@ -1143,6 +1145,8 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> {"dstmac", required_argument, NULL, 'b'},
> {"srcip", required_argument, NULL, 's'},
> {"dstip", required_argument, NULL, 'd'},
> +   {"srcport", required_argument, NULL, 'e'},
> +   {"dstport", required_argument, NULL, 'f'},
> {"packetsize", required_argument, NULL, 'p'},
> {"mode", required_argument, NULL, 'm'},
> {"count", required_argument, NULL, 'n'},
> @@ -1153,7 +1157,7 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> {NULL, 0, NULL, 0}
> };
>
> -   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
> +   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
>
> /* let helper collect its own arguments (e.g. --odph_proc) */
> odph_parse_options(argc, argv, shortopts, longopts);
> @@ -1164,6 +1168,8 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> appl_args->timeout = -1;
> appl_args->interval = DEFAULT_PKT_INTERVAL;
> appl_args->udp_tx_burst = 16;
> +   appl_args->srcport = 0;
> +   appl_args->dstport = 0;
>
> opterr = 0; /* do not issue errors on helper options */
>
> @@ -1270,6 +1276,12 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> }
> break;
>
> +   case 'e':
> +   appl_args->srcport = (unsigned short)atoi(optarg);
> +   break;
> +   case 'f':
> +   appl_args->dstport = (unsigned short)atoi(optarg);
> +   break;
> case 'p':
> appl_args->payload = atoi(optarg);
> break;
> @@ -1383,6 +1395,8 @@ static void usage(char *progname)
>"\n"
>"Optional OPTIONS\n"
>"  -h, --help   Display help and exit.\n"
> +  "  -e, --srcport src udp port\n"
> +  "  -f, --dstport dst udp port\n"
>"  -p, --packetsize payload length of the packets\n"
>"  -t, --timeout only for ping mode, wait ICMP reply timeout 
> seconds\n"
>"  -i, --interval wait interval ms between sending each 
> packet\n"
> --
> 1.9.1
>


[lng-odp] [RFCv3] dpdk: enable hardware checksum support

2017-05-18 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 102 +++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 150 +++--
 3 files changed, 235 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index ede1cdf..59f7f02 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -90,6 +91,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -114,6 +116,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -192,7 +197,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,7 +243,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->dst_port = 0;
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum)
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
 
return pkt;
 }
@@ -251,7 +258,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -273,7 +281,17 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_has_ipv4_set(pkt, 1);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   odp_packet_has_udp_set(pkt, 1);
+   }
 
return pkt;
 }
@@ -342,7 +360,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -367,7 +386,9 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -381,6 +402,13 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_

[lng-odp] [RFCv3] dpdk pktio: enable hardware checksum support

2017-05-18 Thread Bogdan Pricope
v3:
 - RX - enable offload only for supported ptypes
 - TX - no offload is odp packet does not have correct protocol flags
 - TX - use packet header flags instead of public API
v2:
 - add drop_XXX_err support
 - use mbuf packet type flags in interpreting offload results

Bogdan Pricope (1):
  dpdk: enable hardware checksum support

 example/generator/odp_generator.c  | 102 +++---
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 150 +++--
 3 files changed, 235 insertions(+), 19 deletions(-)

-- 
1.9.1



Re: [lng-odp] IPsec crypto algorithms summary

2017-05-18 Thread Bogdan Pricope
Is less about what is deprecated and more about what HW support is
available on already deployed solutions.

On 18 May 2017 at 10:27, Peltonen, Janne (Nokia - FI/Espoo)
 wrote:
> Hi,
>
> The IPsec and IKE document roadmap (RFC 6071) is a good summary about
> the required crypto-algorithms, among other things.
>
> Bill Fischofer wrote:
>> On Wed, May 17, 2017 at 7:07 PM, Dmitry Eremin-Solenikov <
>> dmitry.ereminsoleni...@linaro.org> wrote:
>>
>> > I think, linux-generic should support the following algorihms:
>> >
>> > Cipher:
>> >
>> > - AES-CBC (MUST)
>> > - AES-CTR (MAY)
>> > - 3DES-CBC (MAY)
>> >
>>
>> 3DES appears to be nearing end of life, especially with the recent sweet32
>> [1] attacks so this may be more of a "nice to have", though I see no harm
>> in including it for compatibility. I doubt if many new ODP applications
>> would use 3DES in preference to AES at this point.
>>
>
> 3DES-CBC is still mandatory in IPsec so it is good to keep it.
>
> And besides that, new ODP applications may have to interoperate with
> other systems in existing network deployments that may still use some
> of the older algorithms. I think the benefit of removing an existing
> algorithm implementation is small compared to the trouble it could
> cause in these cases.
>
>> >
>> > Auth:
>> >
>> > - HMAC-SHA1 (MUST)
>> > - HMAC-SHA256/384/512 (optional)
>> > - HMAC-MD5 (unspecified, was MAY)
>> >
>>
>> MD5 is already deprecated [2], and SHA-1 doesn't seem to have long to live
>> either [2]. Enough people still use SHA-1 that it seems we should support
>> it but I think it is safe to drop MD5 support at this point.
>
> HMAC-MD5-96 is optional (MAY) and HMAC-SHA-1-96 is mandatory (MUST) in IPsec.
> The weaknesses of MD5 used as a hash do not necessarily affect HMAC-MD5.
> See RFC 4835, RFC 6151.
>
> The point about interoperability also applies.
>
> Janne
>
>> [1] https://www.openssl.org/blog/blog/2016/08/24/sweet32/
>> [2] https://www.nsrl.nist.gov/collision.html
>> [3] http://csrc.nist.gov/groups/ST/hash/policy.html


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

2017-05-15 Thread Bogdan Pricope
There is a v2 (and soon a v3).

On 15 May 2017 at 16:27, Peltonen, Janne (Nokia - FI/Espoo)
<janne.pelto...@nokia.com> wrote:
>
> Bogdan Pricope wrote:
>> On 10 May 2017 at 20:06, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia.com> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> >> Bogdan Pricope
>> >> Sent: Wednesday, May 10, 2017 4:50 PM
>> >> To: lng-odp@lists.linaro.org
>> >> Subject: [lng-odp] [RFC] dpdk: enable hardware checksum support
>> >>
>> >> Purpose of this RFC is to highlight/discuss different issue observed while
>> >> enabling DPDK checksum calculation/validation:
>> >>  - TX: DPDK needs L2 len, L3 len, L3 protocol, L4 protocol. Should we
>> >> force application to set L2 offset, L3 offset etc. or ODP should parse?
>> >
>> >
>> > /**
>> >  * Packet output configuration options bit field
>> >  *
>> >  * Packet output configuration options listed in a bit field structure. 
>> > Packet
>> >  * output checksum insertion may be enabled or disabled. When it is 
>> > enabled,
>> >  * implementation will calculate and insert checksum into every outgoing 
>> > packet
>> >  * by default. Application may use a packet metadata flag to disable 
>> > checksum
>> >  * insertion per packet bases. For correct operation, packet metadata must
>> >  * provide valid offsets for the appropriate protocols. For example, UDP
>> >  * checksum calculation needs both L3 and L4 offsets (to access IP and UDP
>> > -
>> >  * headers). When application (e.g. a switch) does not modify L3/L4 data 
>> > and
>> >  * thus checksum does not need to be updated, output checksum insertion 
>> > should
>> >  * be disabled for optimal performance.
>> >  */
>> > typedef union odp_pktout_config_opt_t {
>> >
>> >
>> >
>> > API already says that outgoing packet must have (L3/L4) offsets set 
>> > correctly if (e.g.
>> L4) checksum calculation is offloaded.
>>
>> Fine with me. Applications (likw ofp) needs to make sure that will
>> always set all the offsets/protocols, etc.
>
> The API says that the L3/L4 offsets need to be set correctly but it does
> not say anything about the packet flags. If the packet flags need to be
> set too, then I think the API should explicitly say so. And tell also what
> happens if the packet flags do not match the packet (e.g. L3 offset is
> set and points to an IPv4 header but has_ipv4 packet flag is not set).

Csum value will be invalid if L3/L4 flags do not match the packet.

I guess is the same if application provide wrong offsets.

v3 will have some changes on this part.

>
>>
>> >
>> >
>> >
>> >
>> >> Note: application cannot compute checksum or let HW do it until it
>> >> identifies TX interface. This is odd considering OSI model.
>> >>  - RX: application needs to know interface offload settings in order to
>> >> trust error flags received with the packet (e.g. validation was performed
>> >> and result is OK vs. validation was not performed due to no support). It
>> >> may not be trivial for application so I suggest this information to be
>> >> delivered by ODP in packet metadata.
>> >
>> > /**
>> >  * Packet input configuration options bit field
>> >  *
>> >  * Packet input configuration options listed in a bit field structure. 
>> > Packet
>> >  * input timestamping may be enabled for all packets or at least for those 
>> > that
>> >  * belong to time synchronization protocol (PTP).
>> >  *
>> >  * Packet input checksum checking may be enabled or disabled. When it is
>> >  * enabled, implementation will verify checksum correctness on incoming 
>> > packets
>> >  * and depending on drop configuration either deliver erroneous packets 
>> > with
>> >  * appropriate flags set (e.g. odp_packet_has_l3_error()) or drop those.
>> >  * When packet dropping is enabled, application will never receive a packet
>> >  * with the specified error and may avoid to check the error flag.
>> >  */
>> > typedef union odp_pktin_config_opt_t {
>> >
>> >
>> > Application itself configures input checksum offload on/off and should 
>> > remember 

[lng-odp] [RFCv2] dpdk: enable hardware checksum support

2017-05-15 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 102 
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 117 +++--
 3 files changed, 202 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index ede1cdf..59f7f02 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -90,6 +91,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -114,6 +116,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -192,7 +197,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,7 +243,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->dst_port = 0;
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum)
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
 
return pkt;
 }
@@ -251,7 +258,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -273,7 +281,17 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_has_ipv4_set(pkt, 1);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   odp_packet_has_udp_set(pkt, 1);
+   }
 
return pkt;
 }
@@ -342,7 +360,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -367,7 +386,9 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -381,6 +402,13 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_

[lng-odp] [RFCv2] dpdk pktio: enable hardware checksum support

2017-05-15 Thread Bogdan Pricope
v2:
 - add drop_XXX_err support
 - use mbuf packet type flags in interpreting offload results

Bogdan Pricope (1):
  dpdk: enable hardware checksum support

 example/generator/odp_generator.c  | 102 
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c| 117 +++--
 3 files changed, 202 insertions(+), 19 deletions(-)

-- 
1.9.1



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

2017-05-11 Thread Bogdan Pricope
On 10 May 2017 at 20:06, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Bogdan Pricope
>> Sent: Wednesday, May 10, 2017 4:50 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [RFC] dpdk: enable hardware checksum support
>>
>> Purpose of this RFC is to highlight/discuss different issue observed while
>> enabling DPDK checksum calculation/validation:
>>  - TX: DPDK needs L2 len, L3 len, L3 protocol, L4 protocol. Should we
>> force application to set L2 offset, L3 offset etc. or ODP should parse?
>
>
> /**
>  * Packet output configuration options bit field
>  *
>  * Packet output configuration options listed in a bit field structure. Packet
>  * output checksum insertion may be enabled or disabled. When it is enabled,
>  * implementation will calculate and insert checksum into every outgoing 
> packet
>  * by default. Application may use a packet metadata flag to disable checksum
>  * insertion per packet bases. For correct operation, packet metadata must
>  * provide valid offsets for the appropriate protocols. For example, UDP
>  * checksum calculation needs both L3 and L4 offsets (to access IP and UDP
> -
>  * headers). When application (e.g. a switch) does not modify L3/L4 data and
>  * thus checksum does not need to be updated, output checksum insertion should
>  * be disabled for optimal performance.
>  */
> typedef union odp_pktout_config_opt_t {
>
>
>
> API already says that outgoing packet must have (L3/L4) offsets set correctly 
> if (e.g. L4) checksum calculation is offloaded.

Fine with me. Applications (likw ofp) needs to make sure that will
always set all the offsets/protocols, etc.

>
>
>
>
>> Note: application cannot compute checksum or let HW do it until it
>> identifies TX interface. This is odd considering OSI model.
>>  - RX: application needs to know interface offload settings in order to
>> trust error flags received with the packet (e.g. validation was performed
>> and result is OK vs. validation was not performed due to no support). It
>> may not be trivial for application so I suggest this information to be
>> delivered by ODP in packet metadata.
>
> /**
>  * Packet input configuration options bit field
>  *
>  * Packet input configuration options listed in a bit field structure. Packet
>  * input timestamping may be enabled for all packets or at least for those 
> that
>  * belong to time synchronization protocol (PTP).
>  *
>  * Packet input checksum checking may be enabled or disabled. When it is
>  * enabled, implementation will verify checksum correctness on incoming 
> packets
>  * and depending on drop configuration either deliver erroneous packets with
>  * appropriate flags set (e.g. odp_packet_has_l3_error()) or drop those.
>  * When packet dropping is enabled, application will never receive a packet
>  * with the specified error and may avoid to check the error flag.
>  */
> typedef union odp_pktin_config_opt_t {
>
>
> Application itself configures input checksum offload on/off and should 
> remember what it configured. Right?

As I said, is not trivial: in odp_generator I used:

itf = [odp_pktio_index(odp_packet_input(pkt))];

That is, for this basic application, pktio index is the interface
index in application's array. That may not be the case in a complex
application where pktios are created/deleted multiple times - you are
forcing application to mirror odp implementation of pktio array or use
workarounds (OFP is looping through the list of interfaces searching
by pktio handle).

Then, application may need to store offload capabilities of the
interface with the packet for easy processing: application may use its
own metadata in pkt user area or use packet user pointer
ofp:
odp_packet_user_ptr_set(pkt, ifnet);

Bottom line is, will be more efficient if ODP will provide this data
(what offloading operation were performed on a packet) with pkt
metadata since result in case of error is already there.


>
>
>> Note: DPDK has PKT_RX_L4_CKSUM_UNKNOWN, PKT_RX_L4_CKSUM_BAD,
>> PKT_RX_L4_CKSUM_GOOD and PKT_RX_L4_CKSUM_NONE. ODP may have one bit in
>> „pkt_hdr->p.error_flags” and one in „pkt_hdr->p.input_flags”.
>>  - RX: DPDK provides one L4 error flag while ODP keeps flags per protocol
>> (pkt_hdr->p.error_flags.udp_err and pkt_hdr->p.error_flags.tcp_err) but
>> have only one public API for this: odp_packet_has_l4_error()
>>  - RX: Do we (ODP) still need pktin configuration options drop_XXX_err
>> (e.g. drop_ipv4_err, drop_udp_er

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

2017-05-10 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c  | 102 -
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c|  96 +--
 3 files changed, 181 insertions(+), 19 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index ede1cdf..5a8fee4 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -46,6 +46,7 @@
 
 typedef struct {
odp_pktio_t pktio;
+   odp_pktio_config_t config;
odp_pktout_queue_t pktout[MAX_WORKERS];
unsigned pktout_count;
 } interface_t;
@@ -90,6 +91,7 @@ static struct {
  */
 typedef struct {
odp_pktout_queue_t pktout; /**< Packet output queue to use*/
+   odp_pktout_config_opt_t *pktout_cfg; /**< Packet output offload config*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -114,6 +116,9 @@ static args_t *args;
 /** Barrier to sync threads execution */
 static odp_barrier_t barrier;
 
+/** List of interfaces */
+static interface_t *ifs;
+
 /* helper funcs */
 static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
@@ -192,7 +197,8 @@ static int scan_ip(char *buf, unsigned int *paddr)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
+static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -237,7 +243,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
udp->dst_port = 0;
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(pkt);
+   if (!pktout_cfg->bit.udp_chksum)
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
 
return pkt;
 }
@@ -251,7 +258,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -273,7 +281,17 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+
+   if (pktout_cfg->bit.ipv4_chksum || pktout_cfg->bit.udp_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
+   odp_packet_has_ipv4_set(pkt, 1);
+   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + 
ODPH_IPV4HDR_LEN);
+   odp_packet_has_udp_set(pkt, 1);
+   }
 
return pkt;
 }
@@ -342,7 +360,8 @@ static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
  * @return Handle of created packet
  * @retval ODP_PACKET_INVALID  Packet could not be created
  */
-static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
+static odp_packet_t pack_icmp_pkt(odp_pool_t pool, odp_packet_t pkt_ref,
+ 
odp_pktout_config_opt_t *pktout_cfg)
 {
odp_packet_t pkt;
char *buf;
@@ -367,7 +386,9 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
seq = odp_atomic_fetch_add_u64(, 1) % 0x;
ip->id = odp_cpu_to_be_16(seq);
-   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
+   ip->chksum = 0;
+   if (!pktout_cfg->bit.ipv4_chksum)
+   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
 
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
@@ -381,6 +402,13 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
+   if (pktout_cfg->bit.ipv4_chksum) {
+   odp_packet_l2_offset_set(pkt, 0);
+   odp_

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

2017-05-10 Thread Bogdan Pricope
Purpose of this RFC is to highlight/discuss different issue observed while 
enabling DPDK checksum calculation/validation:
 - TX: DPDK needs L2 len, L3 len, L3 protocol, L4 protocol. Should we force 
application to set L2 offset, L3 offset etc. or ODP should parse?
Note: application cannot compute checksum or let HW do it until it identifies 
TX interface. This is odd considering OSI model.
 - RX: application needs to know interface offload settings in order to trust 
error flags received with the packet (e.g. validation was performed and result 
is OK vs. validation was not performed due to no support). It may not be 
trivial for application so I suggest this information to be delivered by ODP in 
packet metadata.
Note: DPDK has PKT_RX_L4_CKSUM_UNKNOWN, PKT_RX_L4_CKSUM_BAD, 
PKT_RX_L4_CKSUM_GOOD and PKT_RX_L4_CKSUM_NONE. ODP may have one bit in 
„pkt_hdr->p.error_flags” and one in „pkt_hdr->p.input_flags”.
 - RX: DPDK provides one L4 error flag while ODP keeps flags per protocol 
(pkt_hdr->p.error_flags.udp_err and pkt_hdr->p.error_flags.tcp_err) but have 
only one public API for this: odp_packet_has_l4_error() 
 - RX: Do we (ODP) still need pktin configuration options drop_XXX_err (e.g. 
drop_ipv4_err, drop_udp_err)? If true, maybe we should keep only one for L4.


Bogdan Pricope (1):
  dpdk pktio: enable hardware checksum support

 example/generator/odp_generator.c  | 102 -
 platform/linux-generic/odp_packet_io.c |   2 +
 platform/linux-generic/pktio/dpdk.c|  96 +--
 3 files changed, 181 insertions(+), 19 deletions(-)

-- 
1.9.1



Re: [lng-odp] [PATCH API-NEXT v2 3/5] api: ipsec: add soft limit expiration event

2017-05-10 Thread Bogdan Pricope
You mean: generating ONE event in SA lifetime vs. carring around 5
bits for each packet (result) (+ validation), bits that will be mostly
0 and once in SA lifetime will be 1 (if ever. e.g. if soft/hard limits
supported/enabled). I see it as a inefficient design.

On 9 May 2017 at 21:37, Bala Manoharan <bala.manoha...@linaro.org> wrote:
> On 9 May 2017 at 00:04, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>> Hi,
>>
>> Can we have this event for all cases: sync/async/inline,
>> inbound/outbound, soft/hard limits? Lifetime expiration is destined to
>> control part of the application... we should be able to process it on
>> a different thread/queue.
>
> In the other cases you have mentioned the packet has to be still sent
> to the application, generating an event will be an additional work and
> there is an additional buffer allocated for the event which could have
> been avoided. I believe there will always be use cases where the data
> thread will have to communicate with control path.
>
> Regards,
> Bala
>>
>> Soft limit - will not affect normal processing of packets - no need
>> for flags as worker does not need to know this; control should
>> renegotiate/cleanup/etc.
>> Hard limits - worker should drop the packet (if platform will not drop
>> the packet for it); control should renegotiate/cleanup/etc.
>>
>> BR,
>> Bogdan
>>
>>
>> On 9 May 2017 at 03:00, Github ODP bot <odp...@yandex.ru> wrote:
>>> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>
>>>
>>> If outbound packet was processed in inline mode, soft limit expiration
>>> event is not reported, as packet goes to the interface. Instead report
>>> this as an ODP_IPSEC_STATUS_SA_SOFT_EXPIRED.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>
>>> ---
>>> /** Email created from pull request 22 (lumag:ipsec-limits)
>>>  ** https://github.com/Linaro/odp/pull/22
>>>  ** Patch: https://github.com/Linaro/odp/pull/22.patch
>>>  ** Base sha: 3ea9c1dac34e0fb4785b0d643056c731daa55e85
>>>  ** Merge commit sha: 85b927011c941f816b853da7284c0c3a939c5efb
>>>  **/
>>>  include/odp/api/spec/ipsec.h | 9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
>>> index e83494d..c4fe6cb 100644
>>> --- a/include/odp/api/spec/ipsec.h
>>> +++ b/include/odp/api/spec/ipsec.h
>>> @@ -1080,7 +1080,14 @@ typedef struct odp_ipsec_op_result_t {
>>>   */
>>>  typedef enum odp_ipsec_status_id_t {
>>> /** Response to SA disable command */
>>> -   ODP_IPSEC_STATUS_SA_DISABLE = 0
>>> +   ODP_IPSEC_STATUS_SA_DISABLE = 0,
>>> +
>>> +   /**
>>> +* Soft limit expired on this SA
>>> +*
>>> +* This event is sent only if SA was configured in OUT INLINE mode.
>>> +*/
>>> +   ODP_IPSEC_STATUS_SA_SOFT_EXPIRED
>>>
>>>  } odp_ipsec_status_id_t;
>>>
>>>


Re: [lng-odp] [PATCH API-NEXT v2 3/5] api: ipsec: add soft limit expiration event

2017-05-09 Thread Bogdan Pricope
Hi,

Can we have this event for all cases: sync/async/inline,
inbound/outbound, soft/hard limits? Lifetime expiration is destined to
control part of the application... we should be able to process it on
a different thread/queue.

Soft limit - will not affect normal processing of packets - no need
for flags as worker does not need to know this; control should
renegotiate/cleanup/etc.
Hard limits - worker should drop the packet (if platform will not drop
the packet for it); control should renegotiate/cleanup/etc.

BR,
Bogdan


On 9 May 2017 at 03:00, Github ODP bot  wrote:
> From: Dmitry Eremin-Solenikov 
>
> If outbound packet was processed in inline mode, soft limit expiration
> event is not reported, as packet goes to the interface. Instead report
> this as an ODP_IPSEC_STATUS_SA_SOFT_EXPIRED.
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
> /** Email created from pull request 22 (lumag:ipsec-limits)
>  ** https://github.com/Linaro/odp/pull/22
>  ** Patch: https://github.com/Linaro/odp/pull/22.patch
>  ** Base sha: 3ea9c1dac34e0fb4785b0d643056c731daa55e85
>  ** Merge commit sha: 85b927011c941f816b853da7284c0c3a939c5efb
>  **/
>  include/odp/api/spec/ipsec.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index e83494d..c4fe6cb 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -1080,7 +1080,14 @@ typedef struct odp_ipsec_op_result_t {
>   */
>  typedef enum odp_ipsec_status_id_t {
> /** Response to SA disable command */
> -   ODP_IPSEC_STATUS_SA_DISABLE = 0
> +   ODP_IPSEC_STATUS_SA_DISABLE = 0,
> +
> +   /**
> +* Soft limit expired on this SA
> +*
> +* This event is sent only if SA was configured in OUT INLINE mode.
> +*/
> +   ODP_IPSEC_STATUS_SA_SOFT_EXPIRED
>
>  } odp_ipsec_status_id_t;
>
>


Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-05-03 Thread Bogdan Pricope
Hi Yi,

I disagree:  bytes sent in Data field of Echo request are opaque and
have no meaning for any other entity then ‘me’ (the sender of echo
request / receiver of echo reply).

The only obligation of the receiver of echo request, as stated by RFC 792 is:
“The data received in the echo message must be returned in the echo
reply message.”

There is no standardization on what should be there (some even using
it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
whatever sender wants –endianness transformations are not useful in
this case.

BR,
Bogdan

On 19 April 2017 at 06:08, Yi He <yi...@linaro.org> wrote:
> Hi, Bogdan
>
> Consider endianness for this uint64_t time value carried in ICMP packets,
> need htonl and ntohl here.
>
> Best Regards, Yi
>
>
>
> On 11 April 2017 at 19:31, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>>
>> Ping!
>>
>>
>> On 3 April 2017 at 13:00, Bogdan Pricope <bogdan.pric...@linaro.org>
>> wrote:
>> > Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
>> > ---
>> >  example/generator/odp_generator.c | 89
>> > ++-
>> >  1 file changed, 41 insertions(+), 48 deletions(-)
>> >
>> > diff --git a/example/generator/odp_generator.c
>> > b/example/generator/odp_generator.c
>> > index 95fb543..9c49d94 100644
>> > --- a/example/generator/odp_generator.c
>> > +++ b/example/generator/odp_generator.c
>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
>> > appl_args_t *appl_args);
>> >  static void print_info(char *progname, appl_args_t *appl_args);
>> >  static void usage(char *progname);
>> >  static int scan_ip(char *buf, unsigned int *paddr);
>> > -static void tv_sub(struct timeval *recvtime, struct timeval *sendtime);
>> >  static void print_global_stats(int num_workers);
>> >
>> >  /**
>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>> > odp_packet_t pkt_ref)
>> > char *buf;
>> > odph_ipv4hdr_t *ip;
>> > odph_icmphdr_t *icmp;
>> > -   struct timeval tval;
>> > +   uint64_t tval;
>> > uint8_t *tval_d;
>> > unsigned short seq;
>> >
>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>> > odp_packet_t pkt_ref)
>> > /* icmp */
>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
>> > ODPH_IPV4HDR_LEN);
>> > icmp->un.echo.sequence = ip->id;
>> > +
>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN +
>> >   ODPH_ICMPHDR_LEN);
>> > -   /* TODO This should be changed to use an
>> > -* ODP timer API once one exists. */
>> > -   gettimeofday(, NULL);
>> > -   memcpy(tval_d, , sizeof(struct timeval));
>> > +   tval = odp_time_to_ns(odp_time_local());
>> > +   memcpy(tval_d, , sizeof(uint64_t));
>> > +
>> > icmp->chksum = 0;
>> > icmp->chksum = odph_chksum(icmp, args->appl.payload +
>> > ODPH_ICMPHDR_LEN);
>> >
>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
>> >  }
>> >
>> >  /**
>> > + * Process icmp packets
>> > + *
>> > + * @param  icmp icmp header address
>> > + * @param  msg output buffer
>> > + */
>> > +
>> > +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
>> > +{
>> > +   uint64_t trecv;
>> > +   uint64_t tsend;
>> > +   uint64_t rtt_ms, rtt_us;
>> > +
>> > +   msg[0] = 0;
>> > +
>> > +   if (icmp->type == ICMP_ECHOREPLY) {
>> > +   odp_atomic_inc_u64();
>> > +
>> > +   memcpy(, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
>> > +  sizeof(uint64_t));
>> > +   trecv = odp_time_to_ns(odp_time_local());
>> > +   rtt_ms = (trecv - tsend) / ODP_TIME_MSEC_IN_NS;
>> > +   rtt_us = (trecv - tsend) / ODP_TIME_USEC_IN_NS -
>> > +   1000 * rtt_ms;
>> > +   sprintf(msg,
>> > +   "ICMP Echo Reply seq %d time %"
>> > +   PRIu64 ".%.03" PRIu64" ms",
>> > +   odp_be_to_cpu_16(icmp->un.echo.sequence),
>> > +

[lng-odp] [PATCHv2] examples: generator: UDP ports configuration

2017-05-03 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index ede1cdf..79efe5b 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -64,6 +64,8 @@ typedef struct {
odph_ethaddr_t dstmac;  /**< dest mac addr */
unsigned int srcip; /**< src ip addr */
unsigned int dstip; /**< dest ip addr */
+   uint16_t srcport;   /**< src udp port */
+   uint16_t dstport;   /**< dest udp port */
int mode;   /**< work mode */
int number; /**< packets number to be sent */
int payload;/**< data len */
@@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
odp_packet_has_udp_set(pkt, 1);
udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
-   udp->src_port = 0;
-   udp->dst_port = 0;
+   udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
+   udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
udp->chksum = odph_ipv4_udp_chksum(pkt);
@@ -1143,6 +1145,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{"dstmac", required_argument, NULL, 'b'},
{"srcip", required_argument, NULL, 's'},
{"dstip", required_argument, NULL, 'd'},
+   {"srcport", required_argument, NULL, 'e'},
+   {"dstport", required_argument, NULL, 'f'},
{"packetsize", required_argument, NULL, 'p'},
{"mode", required_argument, NULL, 'm'},
{"count", required_argument, NULL, 'n'},
@@ -1153,7 +1157,7 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{NULL, 0, NULL, 0}
};
 
-   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
+   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
 
/* let helper collect its own arguments (e.g. --odph_proc) */
odph_parse_options(argc, argv, shortopts, longopts);
@@ -1164,6 +1168,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
appl_args->timeout = -1;
appl_args->interval = DEFAULT_PKT_INTERVAL;
appl_args->udp_tx_burst = 16;
+   appl_args->srcport = 0;
+   appl_args->dstport = 0;
 
opterr = 0; /* do not issue errors on helper options */
 
@@ -1270,6 +1276,12 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
}
break;
 
+   case 'e':
+   appl_args->srcport = (unsigned short)atoi(optarg);
+   break;
+   case 'f':
+   appl_args->dstport = (unsigned short)atoi(optarg);
+   break;
case 'p':
appl_args->payload = atoi(optarg);
break;
@@ -1383,6 +1395,8 @@ static void usage(char *progname)
   "\n"
   "Optional OPTIONS\n"
   "  -h, --help   Display help and exit.\n"
+  "  -e, --srcport src udp port\n"
+  "  -f, --dstport dst udp port\n"
   "  -p, --packetsize payload length of the packets\n"
   "  -t, --timeout only for ping mode, wait ICMP reply timeout 
seconds\n"
   "  -i, --interval wait interval ms between sending each packet\n"
-- 
1.9.1



[lng-odp] [PATCHv2] examples: generator: UDP ports configuration

2017-05-03 Thread Bogdan Pricope
Add command line options to configure UDP ports for generated traffic.

v2:
 * replace 'unsigned short' with 'uint16_t'

Bogdan Pricope (1):
  examples: generator: UDP ports configuration

 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

-- 
1.9.1



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

2017-04-28 Thread Bogdan Pricope
On 28 April 2017 at 10:28, Peltonen, Janne (Nokia - FI/Espoo)
 wrote:
> Hi,
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil 
>> Agarwal
>> Sent: Friday, April 28, 2017 9:50 AM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support 
>> sNIC
>> implementation.
>>
>> Signed-off-by: Nikhil Agarwal 
>> ---
>>  include/odp/api/spec/ipsec.h | 62 
>> +---
>>  include/odp/api/spec/packet_io.h | 10 +++
>>  2 files changed, 36 insertions(+), 36 deletions(-)
>>
>> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
>> index e83494d..a2624ff 100644
>> --- a/include/odp/api/spec/ipsec.h
>> +++ b/include/odp/api/spec/ipsec.h
>> @@ -59,8 +59,10 @@ typedef enum odp_ipsec_op_mode_t {
>>   /** Inline IPSEC operation
>> *
>> * Packet input/output is connected directly to IPSEC inbound/outbound
>> -   * processing. Application uses asynchronous or inline IPSEC
>> -   * operations.
>> +   * processing. Application may use asynchronous IPSEC operations.
>> +   * Packet post IPSEC operations are delivered to PKTIO queues. Further
>> +   * classification/Hashing(inbound) will be applicaed to packet post 
>> IPSEC as
>> +   * defined in PKTIO configuration.
>> */
>>   ODP_IPSEC_OP_MODE_INLINE,
>
> The added comment is not valid for asynchronously processed packets which are 
> also
> allowed in the inline operating mode. So maybe the inline-specific comment 
> should
> be reformulated or located elsewhere.
>
>>
>> @@ -226,6 +228,24 @@ typedef struct odp_ipsec_outbound_config_t {
>>
>>  } odp_ipsec_outbound_config_t;
>>
>> +typedef union odp_ipsec_protocols_t {
>> + /** Cipher algorithms */
>> + struct {
>> + /** ODP_IPSEC_ESP */
>> + uint32_t esp: 1;
>> +
>> + /** ODP_IPSEC_AH */
>> + uint32_t ah : 1;
>> +
>> + } bit;
>> +
>> + /** All bits of the bit field structure
>> +  *
>> +  * This field can be used to set/clear all flags, or bitwise
>> +  * operations over the entire structure. */
>> + uint32_t all_bits;
>> +} odp_ipsec_protocols_t;
>> +
>>  /**
>>   * IPSEC capability
>>   */
>> @@ -264,6 +284,9 @@ typedef struct odp_ipsec_capability_t {
>>*/
>>   uint8_t hard_limit_sec;
>>
>> + /** Supported ipsec Protocols */
>> + odp_ipsec_protocols_t protocols;
>> +
>>   /** Supported cipher algorithms */
>>   odp_crypto_cipher_algos_t ciphers;
>>
>> @@ -554,21 +577,6 @@ typedef enum odp_ipsec_lookup_mode_t {
>>  } odp_ipsec_lookup_mode_t;
>>
>>  /**
>> - * Result event pipeline configuration
>> - */
>> -typedef enum odp_ipsec_pipeline_t {
>> - /** Do not pipeline */
>> - ODP_IPSEC_PIPELINE_NONE = 0,
>> -
>> - /** Send IPSEC result events to the classifier.
>> -  *
>> -  *  IPSEC capability 'pipeline_cls' determines if pipelined
>> -  *  classification is supported. */
>> - ODP_IPSEC_PIPELINE_CLS
>> -
>> -} odp_ipsec_pipeline_t;
>> -
>> -/**
>>   * IPSEC Security Association (SA) parameters
>>   */
>>  typedef struct odp_ipsec_sa_param_t {
>> @@ -632,31 +640,13 @@ typedef struct odp_ipsec_sa_param_t {
>>*/
>>   uint32_t mtu;
>>
>> - /** Select pipelined destination for IPSEC result events
>> -  *
>> -  *  Asynchronous and inline modes generate result events. Select where
>> -  *  those events are sent. Inbound SAs may choose to use pipelined
>> -  *  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
>> -  */
>> - odp_ipsec_pipeline_t pipeline;
>> -
>
> So for asynchronously processed packets this proposal removes the possibility
> of ODP distributing the packets decapsulated from one fat tunnel to multiple
> queues for better parallelism.
>
>>   /** Destination queue for IPSEC events
>>*
>> -  *  Operations in asynchronous or inline mode enqueue resulting events
>> +  *  Operations in asynchronous mode enqueue resulting events
>>*  into this queue.
>>*/
>>   odp_queue_t dest_queue;
>
> So where do the inline processed packets end up? After this patch the
> API would not say it.

Input queues (pktins) of the inbound pktio, applying hashing
configured on that pktio I guess.

>
>>
>> - /** Classifier destination CoS for IPSEC result events
>> -  *
>> -  *  Result events for successfully decapsulated packets are sent to
>> -  *  classification through this CoS. Other result events are sent to
>> -  *  'dest_queue'. This field is considered only when 'pipeline' is
>> -  *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any 
>> pktio
>> -  *  interface default CoS.
>> -  */
>> - odp_cos_t dest_cos;
>> -
>>   /** User defined SA context pointer
>>*
>>   

Re: [lng-odp] [PATCH] examples: generator: UDP ports configuration

2017-04-25 Thread Bogdan Pricope
On 18 April 2017 at 22:13, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 04/12/17 15:54, Bogdan Pricope wrote:
>> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
>> ---
>>  example/generator/odp_generator.c | 20 +---
>>  1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/example/generator/odp_generator.c 
>> b/example/generator/odp_generator.c
>> index 95fb543..4817294 100644
>> --- a/example/generator/odp_generator.c
>> +++ b/example/generator/odp_generator.c
>> @@ -64,6 +64,8 @@ typedef struct {
>>   odph_ethaddr_t dstmac;  /**< dest mac addr */
>>   unsigned int srcip; /**< src ip addr */
>>   unsigned int dstip; /**< dest ip addr */
>> + unsigned short srcport; /**< src udp port */
>> + unsigned short dstport; /**< dest udp port */
>
>
> why unsigned short and not uint16_t ?

We have this rule when modifying code: to keep the look-and-feel of
original code. In this case there are only int, char, unsigned int and
some odp types in this structure. Do you think there is a value in
using ‘uint16_t’ instead of ‘unsigned short’?

>
>
>>   int mode;   /**< work mode */
>>   int number; /**< packets number to be sent */
>>   int payload;/**< data len */
>> @@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>>   odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
>>   odp_packet_has_udp_set(pkt, 1);
>>   udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
>> - udp->src_port = 0;
>> - udp->dst_port = 0;
>> + udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
>> + udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
>>   udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
>>   udp->chksum = 0;
>>   udp->chksum = odph_ipv4_udp_chksum(pkt);
>> @@ -1140,6 +1142,8 @@ static void parse_args(int argc, char *argv[], 
>> appl_args_t *appl_args)
>>   {"dstmac", required_argument, NULL, 'b'},
>>   {"srcip", required_argument, NULL, 's'},
>>   {"dstip", required_argument, NULL, 'd'},
>> + {"srcport", required_argument, NULL, 'e'},
>> + {"dstport", required_argument, NULL, 'f'},
>>   {"packetsize", required_argument, NULL, 'p'},
>>   {"mode", required_argument, NULL, 'm'},
>>   {"count", required_argument, NULL, 'n'},
>> @@ -1150,7 +1154,7 @@ static void parse_args(int argc, char *argv[], 
>> appl_args_t *appl_args)
>>   {NULL, 0, NULL, 0}
>>   };
>>
>> - static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
>> + static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
>>
>>   /* let helper collect its own arguments (e.g. --odph_proc) */
>>   odph_parse_options(argc, argv, shortopts, longopts);
>> @@ -1161,6 +1165,8 @@ static void parse_args(int argc, char *argv[], 
>> appl_args_t *appl_args)
>>   appl_args->timeout = -1;
>>   appl_args->interval = DEFAULT_PKT_INTERVAL;
>>   appl_args->udp_tx_burst = 16;
>> + appl_args->srcport = 0;
>> + appl_args->dstport = 0;
>>
>>   opterr = 0; /* do not issue errors on helper options */
>>
>> @@ -1267,6 +1273,12 @@ static void parse_args(int argc, char *argv[], 
>> appl_args_t *appl_args)
>>   }
>>   break;
>>
>> + case 'e':
>> + appl_args->srcport = (unsigned short)atoi(optarg);
>> + break;
>> + case 'f':
>> + appl_args->dstport = (unsigned short)atoi(optarg);
>> + break;
>>   case 'p':
>>   appl_args->payload = atoi(optarg);
>>   break;
>> @@ -1380,6 +1392,8 @@ static void usage(char *progname)
>>  "\n"
>>  "Optional OPTIONS\n"
>>  "  -h, --help   Display help and exit.\n"
>> +"  -e, --srcport src udp port\n"
>> +"  -f, --dstport dst udp port\n"
>>  "  -p, --packetsize payload length of the packets\n"
>>  "  -t, --timeout only for ping mode, wait ICMP reply timeout 
>> seconds\n"
>>  "  -i, --interval wait interval ms between sending each 
>> packet\n"
>>
>


Re: [lng-odp] [PATCH 0/2] examples: generator: various fixes

2017-04-18 Thread Bogdan Pricope
ping.

On 11 April 2017 at 14:25, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Various fixes for odp_generator.
>
> Bogdan Pricope (2):
>   example: generator: fix stop criteria - number of packets sent
>   example: generator: flush output messages
>
>  example/generator/odp_generator.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> --
> 1.9.1
>


Re: [lng-odp] [PATCH] examples: generator: UDP ports configuration

2017-04-18 Thread Bogdan Pricope
ping.

On 12 April 2017 at 15:54, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  example/generator/odp_generator.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 95fb543..4817294 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -64,6 +64,8 @@ typedef struct {
> odph_ethaddr_t dstmac;  /**< dest mac addr */
> unsigned int srcip; /**< src ip addr */
> unsigned int dstip; /**< dest ip addr */
> +   unsigned short srcport; /**< src udp port */
> +   unsigned short dstport; /**< dest udp port */
> int mode;   /**< work mode */
> int number; /**< packets number to be sent */
> int payload;/**< data len */
> @@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
> odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> odp_packet_has_udp_set(pkt, 1);
> udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> -   udp->src_port = 0;
> -   udp->dst_port = 0;
> +   udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
> +   udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
> udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
> udp->chksum = 0;
> udp->chksum = odph_ipv4_udp_chksum(pkt);
> @@ -1140,6 +1142,8 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> {"dstmac", required_argument, NULL, 'b'},
> {"srcip", required_argument, NULL, 's'},
> {"dstip", required_argument, NULL, 'd'},
> +   {"srcport", required_argument, NULL, 'e'},
> +   {"dstport", required_argument, NULL, 'f'},
> {"packetsize", required_argument, NULL, 'p'},
> {"mode", required_argument, NULL, 'm'},
> {"count", required_argument, NULL, 'n'},
> @@ -1150,7 +1154,7 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> {NULL, 0, NULL, 0}
> };
>
> -   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
> +   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
>
> /* let helper collect its own arguments (e.g. --odph_proc) */
> odph_parse_options(argc, argv, shortopts, longopts);
> @@ -1161,6 +1165,8 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> appl_args->timeout = -1;
> appl_args->interval = DEFAULT_PKT_INTERVAL;
> appl_args->udp_tx_burst = 16;
> +   appl_args->srcport = 0;
> +   appl_args->dstport = 0;
>
> opterr = 0; /* do not issue errors on helper options */
>
> @@ -1267,6 +1273,12 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args)
> }
> break;
>
> +   case 'e':
> +   appl_args->srcport = (unsigned short)atoi(optarg);
> +   break;
> +   case 'f':
> +   appl_args->dstport = (unsigned short)atoi(optarg);
> +   break;
> case 'p':
> appl_args->payload = atoi(optarg);
> break;
> @@ -1380,6 +1392,8 @@ static void usage(char *progname)
>"\n"
>"Optional OPTIONS\n"
>"  -h, --help   Display help and exit.\n"
> +  "  -e, --srcport src udp port\n"
> +  "  -f, --dstport dst udp port\n"
>"  -p, --packetsize payload length of the packets\n"
>"  -t, --timeout only for ping mode, wait ICMP reply timeout 
> seconds\n"
>"  -i, --interval wait interval ms between sending each 
> packet\n"
> --
> 1.9.1
>


[lng-odp] [PATCH] examples: generator: UDP ports config

2017-04-12 Thread Bogdan Pricope
Add command line options to configure UDP ports for generated traffic.

Bogdan Pricope (1):
  examples: generator: UDP ports configuration

 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

-- 
1.9.1



[lng-odp] [PATCH] examples: generator: UDP ports configuration

2017-04-12 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 95fb543..4817294 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -64,6 +64,8 @@ typedef struct {
odph_ethaddr_t dstmac;  /**< dest mac addr */
unsigned int srcip; /**< src ip addr */
unsigned int dstip; /**< dest ip addr */
+   unsigned short srcport; /**< src udp port */
+   unsigned short dstport; /**< dest udp port */
int mode;   /**< work mode */
int number; /**< packets number to be sent */
int payload;/**< data len */
@@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
odp_packet_has_udp_set(pkt, 1);
udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
-   udp->src_port = 0;
-   udp->dst_port = 0;
+   udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
+   udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
udp->chksum = odph_ipv4_udp_chksum(pkt);
@@ -1140,6 +1142,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{"dstmac", required_argument, NULL, 'b'},
{"srcip", required_argument, NULL, 's'},
{"dstip", required_argument, NULL, 'd'},
+   {"srcport", required_argument, NULL, 'e'},
+   {"dstport", required_argument, NULL, 'f'},
{"packetsize", required_argument, NULL, 'p'},
{"mode", required_argument, NULL, 'm'},
{"count", required_argument, NULL, 'n'},
@@ -1150,7 +1154,7 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{NULL, 0, NULL, 0}
};
 
-   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
+   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
 
/* let helper collect its own arguments (e.g. --odph_proc) */
odph_parse_options(argc, argv, shortopts, longopts);
@@ -1161,6 +1165,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
appl_args->timeout = -1;
appl_args->interval = DEFAULT_PKT_INTERVAL;
appl_args->udp_tx_burst = 16;
+   appl_args->srcport = 0;
+   appl_args->dstport = 0;
 
opterr = 0; /* do not issue errors on helper options */
 
@@ -1267,6 +1273,12 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
}
break;
 
+   case 'e':
+   appl_args->srcport = (unsigned short)atoi(optarg);
+   break;
+   case 'f':
+   appl_args->dstport = (unsigned short)atoi(optarg);
+   break;
case 'p':
appl_args->payload = atoi(optarg);
break;
@@ -1380,6 +1392,8 @@ static void usage(char *progname)
   "\n"
   "Optional OPTIONS\n"
   "  -h, --help   Display help and exit.\n"
+  "  -e, --srcport src udp port\n"
+  "  -f, --dstport dst udp port\n"
   "  -p, --packetsize payload length of the packets\n"
   "  -t, --timeout only for ping mode, wait ICMP reply timeout 
seconds\n"
   "  -i, --interval wait interval ms between sending each packet\n"
-- 
1.9.1



Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-04-11 Thread Bogdan Pricope
Ping!


On 3 April 2017 at 13:00, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  example/generator/odp_generator.c | 89 
> ++-
>  1 file changed, 41 insertions(+), 48 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 95fb543..9c49d94 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[], 
> appl_args_t *appl_args);
>  static void print_info(char *progname, appl_args_t *appl_args);
>  static void usage(char *progname);
>  static int scan_ip(char *buf, unsigned int *paddr);
> -static void tv_sub(struct timeval *recvtime, struct timeval *sendtime);
>  static void print_global_stats(int num_workers);
>
>  /**
> @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
> odp_packet_t pkt_ref)
> char *buf;
> odph_ipv4hdr_t *ip;
> odph_icmphdr_t *icmp;
> -   struct timeval tval;
> +   uint64_t tval;
> uint8_t *tval_d;
> unsigned short seq;
>
> @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
> odp_packet_t pkt_ref)
> /* icmp */
> icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> icmp->un.echo.sequence = ip->id;
> +
> tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN +
>   ODPH_ICMPHDR_LEN);
> -   /* TODO This should be changed to use an
> -* ODP timer API once one exists. */
> -   gettimeofday(, NULL);
> -   memcpy(tval_d, , sizeof(struct timeval));
> +   tval = odp_time_to_ns(odp_time_local());
> +   memcpy(tval_d, , sizeof(uint64_t));
> +
> icmp->chksum = 0;
> icmp->chksum = odph_chksum(icmp, args->appl.payload + 
> ODPH_ICMPHDR_LEN);
>
> @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
>  }
>
>  /**
> + * Process icmp packets
> + *
> + * @param  icmp icmp header address
> + * @param  msg output buffer
> + */
> +
> +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
> +{
> +   uint64_t trecv;
> +   uint64_t tsend;
> +   uint64_t rtt_ms, rtt_us;
> +
> +   msg[0] = 0;
> +
> +   if (icmp->type == ICMP_ECHOREPLY) {
> +   odp_atomic_inc_u64();
> +
> +   memcpy(, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
> +  sizeof(uint64_t));
> +   trecv = odp_time_to_ns(odp_time_local());
> +   rtt_ms = (trecv - tsend) / ODP_TIME_MSEC_IN_NS;
> +   rtt_us = (trecv - tsend) / ODP_TIME_USEC_IN_NS -
> +   1000 * rtt_ms;
> +   sprintf(msg,
> +   "ICMP Echo Reply seq %d time %"
> +   PRIu64 ".%.03" PRIu64" ms",
> +   odp_be_to_cpu_16(icmp->un.echo.sequence),
> +   rtt_ms, rtt_us);
> +   } else if (icmp->type == ICMP_ECHO) {
> +   sprintf(msg, "Icmp Echo Request");
> +   }
> +}
> +
> +/**
>   * Print odp packets
>   *
>   * @param  thr worker id
> @@ -606,16 +639,12 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], 
> unsigned len)
> char *buf;
> odph_ipv4hdr_t *ip;
> odph_icmphdr_t *icmp;
> -   struct timeval tvrecv;
> -   struct timeval tvsend;
> -   double rtt;
> unsigned i;
> size_t offset;
> char msg[1024];
> -   int rlen;
> +
> for (i = 0; i < len; ++i) {
> pkt = pkt_tbl[i];
> -   rlen = 0;
>
> /* only ip pkts */
> if (!odp_packet_has_ipv4(pkt))
> @@ -634,26 +663,8 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], 
> unsigned len)
> /* icmp */
> if (ip->proto == ODPH_IPPROTO_ICMP) {
> icmp = (odph_icmphdr_t *)(buf + offset);
> -   /* echo reply */
> -   if (icmp->type == ICMP_ECHOREPLY) {
> -   odp_atomic_inc_u64();
> -   memcpy(, buf + offset + 
> ODPH_ICMPHDR_LEN,
> -  sizeof(struct timeval));
> -   /* TODO This should be changed to use an
> -* ODP timer API once one exists. */
> -   gettimeofday(, NULL);
> -

[lng-odp] [PATCH 0/2] examples: generator: various fixes

2017-04-11 Thread Bogdan Pricope
Various fixes for odp_generator.

Bogdan Pricope (2):
  example: generator: fix stop criteria - number of packets sent
  example: generator: flush output messages

 example/generator/odp_generator.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
1.9.1



[lng-odp] [PATCH 1/2] example: generator: fix stop criteria - number of packets sent

2017-04-11 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 95fb543..63e3f2b 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -513,8 +513,8 @@ static int gen_send_thread(void *arg)
 
for (;;) {
if (args->appl.number != -1 &&
-   odp_atomic_fetch_add_u64(, 1) >=
-   (unsigned int)args->appl.number)
+   odp_atomic_fetch_add_u64(, pkt_array_size) >=
+   (unsigned int)args->appl.number)
break;
 
if (args->appl.mode == APPL_MODE_UDP) {
-- 
1.9.1



[lng-odp] [PATCH 2/2] example: generator: flush output messages

2017-04-11 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 63e3f2b..ede1cdf 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -464,6 +464,7 @@ static int create_pktio(const char *dev, odp_pool_t pool,
   "  default pktio%02" PRIu64 "\n",
   odp_pktio_to_u64(itf->pktio), dev,
   odp_pktio_to_u64(itf->pktio));
+   fflush(NULL);
 
return 0;
 }
@@ -773,6 +774,7 @@ static void print_global_stats(int num_workers)
pkts_snd, odp_atomic_load_u64(_drops),
pps_snd, maximum_pps_snd,
pkts_rcv, pps_rcv, maximum_pps_rcv);
+   fflush(NULL);
}
 }
 
@@ -855,6 +857,7 @@ int main(int argc, char *argv[])
printf("num worker threads: %i\n", num_workers);
printf("first CPU:  %i\n", odp_cpumask_first());
printf("cpu mask:   %s\n", cpumaskstr);
+   fflush(NULL);
 
/* ping mode need two workers */
if (args->appl.mode == APPL_MODE_PING) {
-- 
1.9.1



[lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-04-03 Thread Bogdan Pricope
This is a fix for Bug 2416 - example/generator/odp_generator.c contains todo 
items

Bogdan Pricope (1):
  test: generator: replace gettimeofday() with ODP API calls

 example/generator/odp_generator.c | 89 ++-
 1 file changed, 41 insertions(+), 48 deletions(-)

-- 
1.9.1



[lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls

2017-04-03 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 89 ++-
 1 file changed, 41 insertions(+), 48 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 95fb543..9c49d94 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[], appl_args_t 
*appl_args);
 static void print_info(char *progname, appl_args_t *appl_args);
 static void usage(char *progname);
 static int scan_ip(char *buf, unsigned int *paddr);
-static void tv_sub(struct timeval *recvtime, struct timeval *sendtime);
 static void print_global_stats(int num_workers);
 
 /**
@@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
char *buf;
odph_ipv4hdr_t *ip;
odph_icmphdr_t *icmp;
-   struct timeval tval;
+   uint64_t tval;
uint8_t *tval_d;
unsigned short seq;
 
@@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
/* icmp */
icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
icmp->un.echo.sequence = ip->id;
+
tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN +
  ODPH_ICMPHDR_LEN);
-   /* TODO This should be changed to use an
-* ODP timer API once one exists. */
-   gettimeofday(, NULL);
-   memcpy(tval_d, , sizeof(struct timeval));
+   tval = odp_time_to_ns(odp_time_local());
+   memcpy(tval_d, , sizeof(uint64_t));
+
icmp->chksum = 0;
icmp->chksum = odph_chksum(icmp, args->appl.payload + ODPH_ICMPHDR_LEN);
 
@@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
 }
 
 /**
+ * Process icmp packets
+ *
+ * @param  icmp icmp header address
+ * @param  msg output buffer
+ */
+
+static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
+{
+   uint64_t trecv;
+   uint64_t tsend;
+   uint64_t rtt_ms, rtt_us;
+
+   msg[0] = 0;
+
+   if (icmp->type == ICMP_ECHOREPLY) {
+   odp_atomic_inc_u64();
+
+   memcpy(, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
+  sizeof(uint64_t));
+   trecv = odp_time_to_ns(odp_time_local());
+   rtt_ms = (trecv - tsend) / ODP_TIME_MSEC_IN_NS;
+   rtt_us = (trecv - tsend) / ODP_TIME_USEC_IN_NS -
+   1000 * rtt_ms;
+   sprintf(msg,
+   "ICMP Echo Reply seq %d time %"
+   PRIu64 ".%.03" PRIu64" ms",
+   odp_be_to_cpu_16(icmp->un.echo.sequence),
+   rtt_ms, rtt_us);
+   } else if (icmp->type == ICMP_ECHO) {
+   sprintf(msg, "Icmp Echo Request");
+   }
+}
+
+/**
  * Print odp packets
  *
  * @param  thr worker id
@@ -606,16 +639,12 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], 
unsigned len)
char *buf;
odph_ipv4hdr_t *ip;
odph_icmphdr_t *icmp;
-   struct timeval tvrecv;
-   struct timeval tvsend;
-   double rtt;
unsigned i;
size_t offset;
char msg[1024];
-   int rlen;
+
for (i = 0; i < len; ++i) {
pkt = pkt_tbl[i];
-   rlen = 0;
 
/* only ip pkts */
if (!odp_packet_has_ipv4(pkt))
@@ -634,26 +663,8 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], 
unsigned len)
/* icmp */
if (ip->proto == ODPH_IPPROTO_ICMP) {
icmp = (odph_icmphdr_t *)(buf + offset);
-   /* echo reply */
-   if (icmp->type == ICMP_ECHOREPLY) {
-   odp_atomic_inc_u64();
-   memcpy(, buf + offset + ODPH_ICMPHDR_LEN,
-  sizeof(struct timeval));
-   /* TODO This should be changed to use an
-* ODP timer API once one exists. */
-   gettimeofday(, NULL);
-   tv_sub(, );
-   rtt = tvrecv.tv_sec*1000 + tvrecv.tv_usec/1000;
-   rlen += sprintf(msg + rlen,
-   "ICMP Echo Reply seq %d time %.1f ",
-   odp_be_to_cpu_16(icmp->un.echo.sequence)
-   , rtt);
-   } else if (icmp->type == ICMP_ECHO) {
-   rlen += sprintf(msg + rlen,
-   "Icmp Echo Request");
-   }
 
-   msg[rlen] = '\0';
+   

Re: [lng-odp] [PATCHv4] test: generator: Updated global statistics calculation to provide useful/easy-to-parse information

2017-03-31 Thread Bogdan Pricope
Hi Maxim, Yi,

Since this part is fresh in our memory, can you please review this
patch as well?

BR,
Bogdan

On 15 March 2017 at 09:48, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
> ---
>  example/generator/odp_generator.c | 57 
> ---
>  1 file changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 8062d87..adb94cc 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -568,7 +568,10 @@ static int gen_recv_thread(void *arg)
>  static void print_global_stats(int num_workers)
>  {
> odp_time_t cur, wait, next;
> -   uint64_t pkts, pkts_prev = 0, pps, maximum_pps = 0;
> +   uint64_t pkts_snd = 0, pkts_snd_prev = 0;
> +   uint64_t pps_snd = 0, maximum_pps_snd = 0;
> +   uint64_t pkts_rcv = 0, pkts_rcv_prev = 0;
> +   uint64_t pps_rcv = 0, maximum_pps_rcv = 0;
> int verbose_interval = 20;
> odp_thrmask_t thrd_mask;
>
> @@ -589,30 +592,40 @@ static void print_global_stats(int num_workers)
> continue;
>
> next = odp_time_sum(cur, wait);
> -
> -   if (args->appl.mode == APPL_MODE_RCV) {
> -   pkts = odp_atomic_load_u64();
> -   printf(" total receive(UDP: %" PRIu64 ")\n", pkts);
> +   switch (args->appl.mode) {
> +   case APPL_MODE_RCV:
> +   pkts_rcv = odp_atomic_load_u64();
> +   break;
> +   case APPL_MODE_PING:
> +   pkts_snd = odp_atomic_load_u64();
> +   pkts_rcv = odp_atomic_load_u64();
> +   break;
> +   case APPL_MODE_UDP:
> +   pkts_snd = odp_atomic_load_u64();
> +   break;
> +   default:
> continue;
> }
>
> -   if (args->appl.mode == APPL_MODE_PING) {
> -   pkts = odp_atomic_load_u64();
> -   printf(" total receive(ICMP: %" PRIu64 ")\n", pkts);
> -   }
> -
> -   pkts = odp_atomic_load_u64();
> -   printf(" total sent: %" PRIu64 ", drops: %" PRIu64 "\n", pkts,
> -  odp_atomic_load_u64(_drops));
> -
> -   if (args->appl.mode == APPL_MODE_UDP) {
> -   pps = (pkts - pkts_prev) / verbose_interval;
> -   if (pps > maximum_pps)
> -   maximum_pps = pps;
> -   printf(" %" PRIu64 " pps, %" PRIu64 " max pps\n",
> -  pps, maximum_pps);
> -   pkts_prev = pkts;
> -   }
> +   pps_snd = (pkts_snd - pkts_snd_prev) / verbose_interval;
> +   pkts_snd_prev = pkts_snd;
> +   if (pps_snd > maximum_pps_snd)
> +   maximum_pps_snd = pps_snd;
> +
> +   pps_rcv = (pkts_rcv - pkts_rcv_prev) / verbose_interval;
> +   pkts_rcv_prev = pkts_rcv;
> +   if (pps_rcv > maximum_pps_rcv)
> +   maximum_pps_rcv = pps_rcv;
> +
> +   printf("sent: %" PRIu64 ", drops: %" PRIu64 ", "
> +   "send rate: %" PRIu64 " pps, "
> +   "max send rate: %" PRIu64 " pps, "
> +   "rcv: %" PRIu64 ", "
> +   "recv rate: %" PRIu64 " pps, "
> +   "max recv rate: %" PRIu64 " pps\n",
> +   pkts_snd, odp_atomic_load_u64(_drops),
> +   pps_snd, maximum_pps_snd,
> +   pkts_rcv, pps_rcv, maximum_pps_rcv);
> }
>  }
>
> --
> 1.9.1
>


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

2017-03-29 Thread Bogdan Pricope
What about:

void odp_packet_out_l3_csum_override(odp_packet_t pkt, odp_bool_t compute);

On 29 March 2017 at 16:16, Maxim Uvarov  wrote:
> On 03/29/17 13:10, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>
>>
>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>> Sent: Wednesday, March 29, 2017 10:26 AM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> 
>> Cc: Bill Fischofer ; lng-odp-forward 
>> 
>> Subject: Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet checksum 
>> control
>>
>> I have few questions for better understanding of usage:
>>
>> if check sum is 0 it will be updated or left as zero.
>> if check sum is some wrong value (i.e. packet was modified), what is 
>> expected?
>> if check sum is valid and this feature supported only in software, what is 
>> expected?
>> Maxim.
>>
>>
>> Current value of the checksum field does not matter. This API (and the per 
>> interface config option) controls only checksum insertion. When enabled, ODP 
>> (HW) calculates checksum (before sending packet out of the interface) and 
>> overwrites the checksum field with the new value. When disabled, ODP does 
>> not overwrite the field.
>>
>> -Petri
>>
>
> I asked about that because of naming is a little bit confusing. How
> about define it as:
>
> void odp_packet_out_l2_csum_update(odp_packet_t pkt, odp_bool_t enable);
> void odp_packet_out_l3_csum_update(odp_packet_t pkt, odp_bool_t enable);
>
> Maxim.


[lng-odp] [PATCHv5 5/5] test: generator: use multiple TX queues in send UDP mode

2017-03-28 Thread Bogdan Pricope
Signed-off-by: Bogdan Pricope <bogdan.pric...@linaro.org>
---
 example/generator/odp_generator.c | 136 +++---
 1 file changed, 84 insertions(+), 52 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 9305aa9..d4184a4 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -39,6 +39,17 @@
 /** Get rid of path in filename - only for unix-type paths using '/' */
 #define NO_PATH(file_name) (strrchr((file_name), '/') ? \
strrchr((file_name), '/') + 1 : (file_name))
+
+/**
+ * Interfaces
+ */
+
+typedef struct {
+   odp_pktio_t pktio;
+   odp_pktout_queue_t pktout[MAX_WORKERS];
+   unsigned pktout_count;
+} interface_t;
+
 /**
  * Parsed command line application arguments
  */
@@ -78,7 +89,7 @@ static struct {
 /** * Thread specific arguments
  */
 typedef struct {
-   char *pktio_dev;/**< Interface name to use */
+   odp_pktout_queue_t pktout; /**< Packet output queue to use*/
odp_pool_t pool;/**< Pool for packet IO */
odp_timer_pool_t tp;/**< Timer pool handle */
odp_queue_t tq; /**< Queue for timeouts */
@@ -382,30 +393,33 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool, 
odp_packet_t pkt_ref)
  * @return The handle of the created pktio object.
  * @warning This routine aborts if the create is unsuccessful.
  */
-static odp_pktio_t create_pktio(const char *dev, odp_pool_t pool,
-   unsigned num_rx_queues)
+static int create_pktio(const char *dev, odp_pool_t pool,
+   unsigned num_rx_queues,
+   unsigned num_tx_queues,
+   interface_t *itf)
 {
-   odp_pktio_t pktio;
odp_pktio_capability_t capa;
int ret;
odp_pktio_param_t pktio_param;
odp_pktin_queue_param_t pktin_param;
+   odp_pktout_queue_param_t pktout_param;
+   odp_pktio_op_mode_t pktout_mode;
 
odp_pktio_param_init(_param);
pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
 
/* Open a packet IO instance */
-   pktio = odp_pktio_open(dev, pool, _param);
+   itf->pktio = odp_pktio_open(dev, pool, _param);
 
-   if (pktio == ODP_PKTIO_INVALID) {
+   if (itf->pktio == ODP_PKTIO_INVALID) {
EXAMPLE_ERR("Error: pktio create failed for %s\n", dev);
-   exit(EXIT_FAILURE);
+   return -1;
}
 
-   if (odp_pktio_capability(pktio, )) {
+   if (odp_pktio_capability(itf->pktio, )) {
EXAMPLE_ERR("Error: Failed to get interface capabilities %s\n",
dev);
-   exit(EXIT_FAILURE);
+   return -1;
}
if (num_rx_queues > capa.max_input_queues)
num_rx_queues = capa.max_input_queues;
@@ -414,27 +428,44 @@ static odp_pktio_t create_pktio(const char *dev, 
odp_pool_t pool,
pktin_param.num_queues = num_rx_queues;
pktin_param.queue_param.sched.sync = ODP_SCHED_SYNC_ATOMIC;
 
-   if (odp_pktin_queue_config(pktio, _param)) {
+   if (odp_pktin_queue_config(itf->pktio, _param)) {
EXAMPLE_ERR("Error: pktin queue config failed for %s\n", dev);
-   exit(EXIT_FAILURE);
+   return -1;
+   }
+
+   pktout_mode = ODP_PKTIO_OP_MT_UNSAFE;
+   if (num_tx_queues > capa.max_output_queues) {
+   num_tx_queues = capa.max_output_queues;
+   pktout_mode = ODP_PKTIO_OP_MT;
}
 
-   if (odp_pktout_queue_config(pktio, NULL)) {
+   odp_pktout_queue_param_init(_param);
+   pktout_param.num_queues = num_tx_queues;
+   pktout_param.op_mode = pktout_mode;
+
+   if (odp_pktout_queue_config(itf->pktio, _param)) {
EXAMPLE_ERR("Error: pktout queue config failed for %s\n", dev);
-   exit(EXIT_FAILURE);
+   return -1;
}
 
-   ret = odp_pktio_start(pktio);
+   ret = odp_pktio_start(itf->pktio);
if (ret)
EXAMPLE_ABORT("Error: unable to start %s\n", dev);
 
+   itf->pktout_count = num_tx_queues;
+   if (odp_pktout_queue(itf->pktio, itf->pktout, itf->pktout_count) !=
+(int)itf->pktout_count) {
+   EXAMPLE_ERR("Error: failed to get output queues for %s\n", dev);
+   return -1;
+   }
+
printf("  created pktio:%02" PRIu64
   ", dev:%s, queue mode (ATOMIC queues)\n"
   "  default pktio%02" PRIu64 "\n",
-  odp_pktio_to_u64(pktio), dev,
-  odp_pktio_to_u64(pktio));
+  odp_pktio_to_u64(itf->pktio), dev,
+  odp_pktio_to_u64(itf->pktio));
 
-   return pktio;
+   return 0;

  1   2   >