RecordTimestamp and TimeStampDiff using the system clock about fastclick HOT 16 CLOSED

The problem in this case was that we half-ported it. Only the push, not the pull. So the compatibility mode does not kick in...

from fastclick.

from fastclick.

The problem is that TimestampDiff reference memory from RecordTimestamp.

The way it works is that packets are numbered with NumberPacket, then checksumed etc. Then generally a Replay element will replay the packet in loop. RecordTimestamp will just keep a mapping of packet index (as indexed per NumberPacket) -> Timestamp.

Then Timestampdiff use the number inside the packet to look in the table and compute the diff.

You have multiple solutions :

• Use the same container with two ports (intended use)
• Change the ecosystem and write the timestamp inside the packet itself. But that will take a lot of time (checksum recomputation etc). Therefore you're looking at using MT-safe operations etc. Hard...
• Share the memory using some IPC system
• Do this offline. Have the table printed by the SRC in some file at the end of the experiment, then have TImestampDiff (another one actually) read it.

from fastclick.

Thanks Tom, much appreciated. Would you recommend to have two cores for the intended use case? Say if the DPDK EAL assigns two cores, would click automatically take care of pinning the two pipelines (i.e. InfiniteSource->....->....->RecordStamp->port1, and port0->....->....->TimeDiff) to separate cores?

from fastclick.

Yes it will. You indeed need two cores for this. Maybe even more.

from fastclick.

Great! One last thing,

//+++++DPDK0 Interface+++++
DPDK0_OUT ::  ToDPDKDevice(0);

//+++++DPDK1 Interface+++++
DPDK1_IN :: FromDPDKDevice(1, PROMISC true); 

//--------Program Start----------
InfiniteSource(LENGTH 64, LIMIT 10000, STOP true)
	-> UDPIP6Encap(2001:2001:2001:2001::1, 1234, 2001:2001:2001:2001::2, 1234)
	-> EtherEncap(0x86DD, 00:04:23:D0:93:63, 00:17:cb:0d:f8:db)
	-> NumberPacket(OFFSET 60)
	-> record:: RecordTimestamp()
	-> DPDK0_OUT;

DPDK1_IN
	-> counter :: AverageCounter()
	-> CheckNumberPacket(OFFSET 60, COUNT 10000)
	-> diff :: TimestampDiff(RECORDER record)
	-> Discard;
//--------Program End----------
DriverManager(wait,read diff.average, read counter.count)

When I start the code above on one core, the diff.average shows -nan. Am I missing something?
When I pass two cores via the EAL, the code doesn't start at all and gives the following error.

While initializing 'DPDK0_OUT :: ToDPDKDevice':
Port 0 can only use 1 RX queues, use MAXQUEUES to set the maximum number of queues or N_QUEUES to strictly define it.

What is it that puzzles clickdpdk with varying core counts?
Thanks!

from fastclick.

You need to compute the offset right. In number packet it is 60+ length of ether + length of encap. Print the packets and find the offset of the increasing number (4 bytes).

Once working, add ReplayUnqueue between numberpacket and record, so all your packets will be prefetched in memory before playing. This will give a more precise latency as here you also compute the latency of numbering packets.

from fastclick.

But if something was wrong with the offset, CheckNumberPacket should have thrown an error right? I made a quick and lazy verification by setting the count of CheckNumberPacket to 9990 and I get "out of scope" error for numbers 9991-10000, which makes me assume that the source and sink pipelines are in agreement on the offset of the 4 bytes number.

Assuming that NumberPacket writes into the payload, the offset is where the payload begins right? So for an IPv6 UDP packet, the offset should be ether 14+ipv6 40+udp 8= 62. Am I off the base? :)

from fastclick.

The offset is according to the data pointer, as moved by encapsulation elements and Strip/Unstrip elements. To test, you could also remove "-> DPDK0_OUT; DPDK1_IN" and not use the link actually. See if your config works.

from fastclick.

Thanks a bunch for bearing with me on this Tom. Our discussion led me to the right direction and I figured out that the TimestampDiff has to point to the offset of the number, that is, the same offset that CheckNumberPacket passes without complaints.

//--------Program Start----------
InfiniteSource(LENGTH 64, LIMIT 10000, STOP true)
        -> NumberPacket(OFFSET 0)
        -> UDPIP6Encap(2001:2001:2001:2001::1, 1234, 2001:2001:2001:2001::2, 1234)
        -> EtherEncap(0x86DD, 00:04:23:D0:93:63, 00:17:cb:0d:f8:db)
	-> record :: RecordTimestamp()
        -> CheckNumberPacket(OFFSET 62, COUNT 10000)
        -> diff :: TimestampDiff(OFFSET 62, RECORDER record)
	-> counter :: AverageCounter()
        -> Discard;
//--------Program End----------

The same works over the link. Now I am trying to make ReplayUnqueue work.

//--------Program Start----------
InfiniteSource(LENGTH 64, LIMIT 100)
        -> NumberPacket(OFFSET 0)
        -> UDPIP6Encap(2001:2001:2001:2001::1, 1234, 2001:2001:2001:2001::2, 1234)
        -> EtherEncap(0x86DD, 00:04:23:D0:93:63, 00:17:cb:0d:f8:db)
	-> replay :: ReplayUnqueue(STOP 1, ACTIVE true, QUICK_CLONE 1)
	-> record :: RecordTimestamp()
        -> CheckNumberPacket(OFFSET 62, COUNT 100)
        -> diff :: TimestampDiff(OFFSET 62, RECORDER record)
	-> counter :: AverageCounter()
        -> Discard;
//--------Program End----------

And I get 100 of
Warning in EtherEncap@6 : simple_action_batch should be implemented. This element is useless, batch will be returned untouched.
Then I get
replay : Successfully loaded 100 packets. Input 0 dried out.
Then I get 100 of
CheckNumberPacket@9 :: CheckNumberPacket : 8079564523421900916 out of scope (count is 100) !

I guess the batch warning is harmless, however it seems like the replay is somehow messing up the packet. I get a segfault when I try to feed replay's output to IP6Print. Any ideas?

from fastclick.

Closing this issue as the inquiry in the title is resolved. Will open another for replayunqueue.
Many thanks!

from fastclick.

Actually the etherencap error is legit and bad, I'm fixing it. Your packet is simply not encaped. It may solve the problem.

from fastclick.

Oh, I assumed it is just the element not supporting batch mode and therefore continuing in traditional mode which is slower. Was planning to implement batch for EtherEncap and UDPIP6Encap once I get the basic functionality working. I gotta be careful next time about the warnings, "This element is useless, batch will be returned untouched." vs "...doesnt support batch mode, will operate slower".

I will test your fix and get back, thanks!

from fastclick.

After applying your commit, etherencap warning disappeared, however the following appeared.

Warning ! Pull UDPIP6Encap@5<-EtherEncap@6 is not compatible with batch. Batching will be disabled and that will reduce performances.
NumberPacket@4 won't be in batch mode because no element produces or sends batches to it.
Initializing DPDK
Loading replay with 1 inputs.
replay : Successfully loaded 150000 packets. Input 0 dried out.

So I went ahead and applied the following patch

diff --git a/elements/tcpudp/udpip6encap.cc b/elements/tcpudp/udpip6encap.cc
index a03603b70..8059375cf 100644
--- a/elements/tcpudp/udpip6encap.cc
+++ b/elements/tcpudp/udpip6encap.cc
@@ -124,6 +124,15 @@ UDPIP6Encap::simple_action(Packet *p_in)
     return p;
 }
 
+#if HAVE_BATCH
+PacketBatch *
+UDPIP6Encap::simple_action_batch(PacketBatch *batch)
+{
+	EXECUTE_FOR_EACH_PACKET(UDPIP6Encap::simple_action,batch);
+	return batch;
+}
+#endif
+
 String UDPIP6Encap::read_handler(Element *e, void *thunk)
 {
     UDPIP6Encap *u = static_cast<UDPIP6Encap *>(e);
diff --git a/elements/tcpudp/udpip6encap.hh b/elements/tcpudp/udpip6encap.hh
index ff1231e1c..0c845ff66 100644
--- a/elements/tcpudp/udpip6encap.hh
+++ b/elements/tcpudp/udpip6encap.hh
@@ -1,6 +1,6 @@
 #ifndef CLICK_UDPIP6ENCAP_HH
 #define CLICK_UDPIP6ENCAP_HH
-#include <click/element.hh>
+#include <click/batchelement.hh>
 #include <click/glue.hh>
 #include <click/atomic.hh>
 #include <clicknet/udp.h>
@@ -53,7 +53,7 @@ Returns or sets the DPORT destination port argument.
 =a Strip
 */
 
-class UDPIP6Encap : public Element { public:
+class UDPIP6Encap : public BatchElement { public:
 
     UDPIP6Encap();
     ~UDPIP6Encap();
@@ -67,6 +67,9 @@ class UDPIP6Encap : public Element { public:
     void add_handlers() CLICK_COLD;
 
     Packet *simple_action(Packet *);
+#if HAVE_BATCH
+    PacketBatch *simple_action_batch(PacketBatch *);
+#endif
 
   private:

Warnings disappeared. However I have very peculiar results. Following are same pipeline results (not over the link)

With replay

Loading replay with 1 inputs.
replay : Successfully loaded 100000 packets. Input 0 dried out.
diff.average:
3.06621
counter.count:
100000

Without replay

Initializing DPDK
diff.average:
0.00303
counter.count:
100000

from fastclick.

The patch seems good. Maybe you can send a PR ? In this case it was just a peformance warning, it did work with compatibility mode. Print the packets maybe to be sure everything seems good ? Print the amount of bytes too from the counter.

from fastclick.

Will check this one as well.
Quick question, what is the unit of diff.average? 3.06621 miliseconds? Couldn't find in the comments in the header file.

from fastclick.