Skip to content
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

Open
fklassen opened this issue Jan 21, 2019 · 7 comments
Open

Assistance with Tcpreplay bad addr/len #582

fklassen opened this issue Jan 21, 2019 · 7 comments
Assignees
Labels

Comments

@fklassen
Copy link

fklassen commented Jan 21, 2019

I'm having the following issue when I attempt to replay packets > 1500 bytes on 9000 MTU interface (Linux) with tcpreplay/netmap.

Jan 21 19:53:02 replay11 kernel: [  159.743146] 382.663361 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 193 idx 195 len 3736
Jan 21 19:53:02 replay11 kernel: [  159.799148] 382.719341 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 195 idx 197 len 2742
Jan 21 19:53:02 replay11 kernel: [  159.854932] 382.775099 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 199 idx 201 len 2742
Jan 21 19:53:02 replay11 kernel: [  159.910695] 382.830837 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 201 idx 203 len 5515
Jan 21 19:53:02 replay11 kernel: [  159.966462] 382.886577 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 203 idx 205 len 2666
Jan 21 19:53:02 replay11 kernel: [  160.022216] 382.942307 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 284 idx 286 len 2964
Jan 21 19:53:03 replay11 kernel: [  160.791758] 383.711497 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 314 idx 316 len 3539
Jan 21 19:53:03 replay11 kernel: [  160.848241] 383.767955 [ 183] ixgbe_netmap_txsync       bad addr/len ring 0 slot 316 idx 318 len 3472

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.

@vmaffione
Copy link
Collaborator

You need to increase /sys/module/netmap/parameters/buf_size.

@vmaffione vmaffione self-assigned this Jan 22, 2019
@giuseppelettieri
Copy link
Collaborator

Yes, the defauit buffer size is 2048. You can either increase that (no change needed in the app, but possibly wasteful) or support NS_MOREFRAG in tcpreplay. Basically, you need to use several consecutive slots for a single message and set NS_MOREFRAG in the slot flags of all but the last slot.

@fklassen
Copy link
Author

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.

@fklassen
Copy link
Author

or support NS_MOREFRAG in tcpreplay. Basically, you need to use several consecutive slots for a single message and set NS_MOREFRAG in the slot flags of all b

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?

@giuseppelettieri
Copy link
Collaborator

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.

@giuseppelettieri
Copy link
Collaborator

giuseppelettieri commented Jan 24, 2019

Does the flag work dynamicallay, e.g. if a 1500 byte packet comes in, will it only take one 2048 byte buffer?

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.

@fklassen
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants