Hi Stuart,
looks like bug with inq fixed. Are going to send updated version?
Thank you,
Maxim.
On 09/10/15 14:24, Stuart Haslam wrote:
On Mon, Sep 07, 2015 at 10:55:21AM +0100, Stuart Haslam wrote:
On Fri, Sep 04, 2015 at 02:50:47PM -0500, Bill Fischofer wrote:
On Fri, Sep 4, 2015 at 8:20 AM, Stuart Haslam <[email protected]>
wrote:
This is pretty handy for testing, for example to test classifier rules
using packets from a pcap;
odp_classifier -ipcap:in=test.pcap -p -m 0
"ODP_PMR_SIP_ADDR:192.168.111.2:FFFFFFFF:queue1"
-t 5
Use the l2fwd app send packets from a pcap out over a real interface;
odp_l2fwd -ipcap:in=test.pcap:loops=10,eth0 -t 5
Check that l2fwd doesn't reorder packets;
odp_l2fwd -m 0 -i pcap:in=test.pcap,pcap:out=test_out.pcap
editcap -v -D 0 test.pcap /dev/null | awk '{print $7}' > test.txt
editcap -v -D 0 test_out.pcap /dev/null | awk '{print $7}' > test_out.txt
diff -q test.txt test_out.txt
(oops, it does when using > 2 workers)
Stuart: Is this with the just-released ODP v1.3 using ordered queues?
Preventing this is what ordered queues are designed to do.
In this case I was running it in "direct" mode, so it's calling
odp_pktio_recv()/_send() directly. Ordering is therefore the
responsibility of the application but it's doing nothing to maintain
order while calling recv/send on the same interface from multiple
threads. I'll raise a bug against the app for that.
It does have a mode in which packets are received via the scheduler,
I'll give that a try. It's using ATOMIC at the minute so it should work,
So that works.
I did have to change the pcap recv function to handle packet allocation
failures without dropping packets though, so I'll send a v2 series. With
a single atomic inq and multiple workers the pktio's default inq quickly
fills up until the pool is exhausted. Normally dropping packets would be
a reasonable way to deal with this overload, but it doesn't make sense
when the source is a pcap file.
it would be interesting to covert to an ORDERED queue
ORDERED PKTIN queues don't seem to work at all;
#3 0x00007f77da83ab8e in pktin_enqueue (qentry=<optimised out>, buf_hdr=<optimised
out>, sustain=<optimised out>) at odp_packet_io.c:536
#4 0x00007f77da84085a in release_order (origin_qe=0x7f77dae0d000, order=<optimised
out>, pool=0x0, enq_called=<optimised out>) at odp_queue.c:912
#5 0x00007f77da841375 in odp_schedule_release_context () at odp_schedule.c:411
#6 0x00007f77da841565 in schedule (max_deq=4, max_num=1,
out_ev=0x7f77d671dcb8, out_queue=0x0) at odp_schedule.c:453
I just replaced ODP_SCHED_SYNC_ATOMIC with ODP_SCHED_SYNC_ORDERED in
odp_l2fwd.c, then ran it with "-m 1".
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
