-
Notifications
You must be signed in to change notification settings - Fork 533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assistance with Tcpreplay bad addr/len #582
Comments
You need to increase |
Yes, the defauit buffer size is 2048. You can either increase that (no change needed in the app, but possibly wasteful) or support |
I am having Tcpreplay crashes when I increase the buffer size dynamically. Does the value have to be a power of two? I am attempting to accept 9018 frames. I'm not sure if I have to alter Tcpreplay source code to make this work. |
I'll add a ticket to add that flag. Question: Does the flag work dynamicallay, e.g. if a 1500 byte packet comes in, will it only take one 2048 byte buffer? |
The buffer size can be any value between 64 and 65536. it doesn't need to be a power of 2, but the number you enter may rounded to a multiple of a cacheline (you should see a message in the logs). The new value is not used while there are netmap applications still running. |
it is a per-slot flag. If you have a packet that fits a single slot, you simply don't set the flag. If you have a packet that needs 4 slots, you set the flag in the first three. |
That makes sense. Thanks for clarifying. Opened appneta/tcpreplay:#534 to track this issue. |
I'm having the following issue when I attempt to replay packets > 1500 bytes on 9000 MTU interface (Linux) with tcpreplay/netmap.
As far as I can tell, this is coming from this debug macro defined as 1.
Is this correct? Or is there something I have to do to TX on interfaces with MTU > 1500.
The overall effect is that performance is very poor, and logs are filling up.
The text was updated successfully, but these errors were encountered: