Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
05-13-2014, 05:58 PM
|
#1
|
LQ Newbie
Registered: May 2014
Posts: 4
Rep: 
|
PF_RING: packet of length 1518 is too long to send?
As a first step to a more complicated application, I am trying to create a bridge with PF_RING Zero Copy. I am running 64-bit Ubuntu 12.04 on a Core i7, and have an Intel X540 dual-port 10Gbps card which uses the ixgbe driver. I run the code included below to forward from one port to the other. When I run it using the default driver, it works, but I don't get the benefit of a PF_RING-aware driver. When I run with the ixgbe driver built in the PF_RING_aware directory of the PF_RING source, it runs until it tries to send a packet of length 1518, at which point pfring_zc_send_pkt() fails with an EMSGSIZE error ("Message too long"). This despite the fact that the packet buffer size is set to 1600 (MTU+100).
It seems that the source for pfring_zc_send_pkt() is hidden; it is only available in compiled form, so I cannot dig further into how exactly it is determined that the message is "too long."
Does anyone have any suggestions on how to proceed? Any configurations to check?
Code:
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <net/ethernet.h>
#include "pfring.h"
#include "pfring_zc.h"
int main(int argc, char* argv[]) {
pfring_zc_cluster *cluster;
int cpu_id;
static u_int32_t buffer_len = ETHERMTU + 100;
static u_int32_t queue_len = 1000;
char *source_dev, *dest_dev;
pfring_zc_queue *recv_queue, *send_queue;
pfring_zc_pkt_buff *recv_buff;
if (argc != 4) {
printf("USAGE: %s <src> <dest> <cpu_id>\n", argv[0]);
exit(-1);
}
// get device names
source_dev = argv[1];
dest_dev = argv[2];
// get CPU ID
cpu_id = atoi(argv[3]);
// create cluster
cluster = pfring_zc_create_cluster(cpu_id, buffer_len,
0, queue_len, numa_node_of_cpu(cpu_id), NULL);
if (cluster == NULL) {
perror("pfring_zc_create_cluster failed");
exit(-1);
}
recv_buff = pfring_zc_get_packet_handle(cluster);
// open devices
recv_queue = pfring_zc_open_device(cluster, source_dev, rx_only, 0);
if (recv_queue == NULL) {
perror("pfring_zc_open_device");
fprintf(stderr, "error opening device %s for receive\n", source_dev);
exit(-1);
}
send_queue = pfring_zc_open_device(cluster, dest_dev, tx_only, 0);
if (send_queue == NULL) {
perror("pfring_zc_open_device");
fprintf(stderr, "error opening device %s for transmit\n", dest_dev);
exit(-1);
}
// forward traffic packet-by-packet
while (1) {
static u_int8_t wait_for_packet = 1;
static u_int8_t flush_packet = 0;
// receive a packet
if (pfring_zc_recv_pkt(recv_queue, &recv_buff, wait_for_packet) < 0) {
perror("error receiving packet");
exit(-1);
}
printf("packet length %d\n", recv_buff->len);
// send a packet
if (pfring_zc_send_pkt(send_queue, &recv_buff, flush_packet) < 0) {
perror("error sending packet");
exit(-1);
}
}
}
|
|
|
05-14-2014, 12:10 PM
|
#2
|
Senior Member
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 4,337
|
|
|
|
05-14-2014, 12:15 PM
|
#3
|
LQ Newbie
Registered: May 2014
Posts: 4
Original Poster
Rep: 
|
Quote:
Originally Posted by smallpond
|
Please elaborate. Are you saying that recv_buff->len only counts the payload, not the whole packet? Because MTU only limits the payload size.
Also, the packet of size 1518 was successfully received by PF_RING, so why can't it be sent?
It is worth noting that I have disabled all packet segmentation offloading on the card, so all packets received should be proper ethernet frames.
|
|
|
05-14-2014, 05:56 PM
|
#4
|
Senior Member
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 4,337
|
Sorry for the short answer. Actually, EMSGSIZE is not a popular error in the kernel. ixgbe generates it only when doing certain ethtool operations, and there are a few places in ipv6 raw, but none jumps out at me. My guess would be pf_ring itself.
|
|
|
05-14-2014, 05:59 PM
|
#5
|
Member
Registered: Oct 2007
Location: BC, Canada
Distribution: Fedora, Debian
Posts: 210
Rep:
|
I didn't realize pfring could send packets - I thought it was only for capture?
|
|
|
05-15-2014, 04:13 PM
|
#6
|
LQ Newbie
Registered: May 2014
Posts: 4
Original Poster
Rep: 
|
Here's an update. I recompiled the ixgbe driver provided with PF_RING, but took out the -DHAVE_PF_RING preprocessor flag in the Makefile. It worked -- no long messages. So the problem is definitely contained in the PF_RING additions. I scanned through the source but didn't find anything obvious. I think I will submit a bug report to ntop.org.
|
|
|
05-27-2014, 03:44 PM
|
#7
|
LQ Newbie
Registered: May 2014
Posts: 4
Original Poster
Rep: 
|
This bug has been fixed in PF_RING revision 7673. The bug report is here, if you have an ntop.org bugzilla account.
|
|
|
All times are GMT -5. The time now is 08:21 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|