anlab-kaist / packet-io-engine Goto Github PK

Hi,

I tried testing the module more with the supplied packet_generator.c - if you add "packet_size = 60 + rand() % 1000;" after the for loop at line 399 (in send_packets()) - this makes the packet size random between 60-1060 bytes long - and after less than 1 minute of sending packets, suddenly PPS drops to zero.

Investigating it I saw that ps_send_chunk() returns 0 (0 packets sent) - and even if I try sending regular 60 byte packets after this - it won't send anything, the driver is dead.

The only workaround to this is to do "ifconfig down" and then "up" - then everything works, but if random sized packets are sent - again the same issue happens.

Any ideas?

Drivers and samples Vlan support is missing.
Testing ps_ixgbe module with rxdump.c shows tagged traffic as untagged, probably by the driver.
Adding native vlans causes all traffic to be dropped.

Hi,

I experienced a lot of times that after using PSIO (loading the module, sending/receiving some packets), if I rmmod ps_ixgbe the kernel module will crash and the machine will reboot.

HOWEVER - if under the same conditions I first issue "ifconfig xge[n] down" for all xge's - and then rmmod the module - it will not crash.

Any ideas

Hi,

It seems as though PSIO can only reach up to around 5M PPS with one core - while other libraries (e.g. netmap) produce full 10G wirespeed results with the same 1 core.

Please improve the performance of PSIO to match it

Thanks!!!

Hi,

Is LACP supported currently?

I'd like to be able to connect two 10G ports to a trunk on a switch..

Thank

Please support Linux kernel 3.6 onwards

I modify the packet generator like this to send the random size packet:

         chunk.queue.ifindex = devices_registered[i];
         working = 1;

+        int offset = 0;

      for (j = 0; j < chunk_size; j++) {
+            
+            packet_size = rand() % 2 + 400;

              chunk.info[j].len = packet_size;
//        chunk.info[j].offset = j * PS_ALIGN(packet_size, 64);
+            chunk.info[j].offset = offset;
+           offset = PS_ALIGN(offset + packet_size, 64);

             if (num_flows == 0){

then I run the command like this:
./packet_generator -i xge0 -p 512 -s 64

I use the libpcap reading the packet at another mechine, use the libnids processing the packet, I find some packet's cap_length - linkoffset is less than ip header's ip total length , like this:

  caplen - linkoffset < ntohs(iph->ip_len)

But the length is not random, it is also the packet we build, it's length should be 401 , but when I receive, it is 400.

For help!!!

I find if I change the flow control state when I am receiving packets, the driver is not work.
example:
if flow control is on.
I use this command:
ethtool -A xge0 autoneg off rx off tx off

then the driver can't receive packets, I must reload the driver.

This issue can also be appear when I hot plug the cable. If I hot plug the cable when I running rx sample, I must reload the driver.

Hello!

Subject :)

Thank you for an answer!

Hello there is a big need for the latest stable kernel version. Could that framework use that?

I realize this is not a software defect - but there have been several important issues opened here in the last 6 months that seem to get ignored :(

Is there anybody maintaining this actively?

Joongi Kim is listed as the current maintainer - are you here? are you reading this? can you please assist people trying to use your code?

The driver's Makefile seems to be malfunctioning as the make command yields a myriad of warnings & the following error:
error: implicit declaration of function ‘SET_ETHTOOL_OPS’ [-Werror=implicit-function-declaration] SET_ETHTOOL_OPS(netdev, &ixgbe_ethtool_ops);

I am wondering is there any way to find out how many packets are being dropped. Either due to device could not handled or the application which was supposed to receive the packets could not handled.

Thanks,
Gurvinder

I am wondering what is the buffer size allocated to the device by default and can I increase the buffer size, so that if the end application is bit slow in processing packets it can handle the bursts by having a large buffer size. Another thing is that the current max allowed chunk size is 4096, which seems to be low for application which need to process the packet not just count.

Last issue is that the drop packet count indicated by ethtool is for whole device, it would be really nice to know the drop count per queue.

Thanks,
Gurvinder