Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

expensive Packet::push; have 0 wanted 14 #474

Open
p4pe opened this issue Jan 4, 2021 · 6 comments
Open

expensive Packet::push; have 0 wanted 14 #474

p4pe opened this issue Jan 4, 2021 · 6 comments

Comments

@p4pe
Copy link

p4pe commented Jan 4, 2021

Hello everyone, I have the following IPSec configuration script:

in::FromDevice(enp4s0f1)
  -> IPPrint("I took the packet")
  -> Strip(14)
  -> CheckIPHeader()
  -> GetIPAddress(16)
  -> ipsec_rt::RadixIPsecLookup( 10.10.1.1/32 0,
192.168.2.0/24 10.10.2.1 1 111 1111111111111111 1111111111111111 1 0 ,
0.0.0.0/0 2
);




ipsec_rt[0]
// Receive
-> Discard;
ipsec_rt[1]
-> IPsecESPEncap()
-> IPsecAuthHMACSHA1(0)
-> IPsecAES(1)
-> UDPIPEncap(10.10.1.1 , 4500 , 192.168.2.5 , 4500)
-> EtherEncap(0x800,3c:fd:fe:04:ad:40,3c:fd:fe:04:c1:e2 )
-> IPPrint("Hello this is an IPSec packet")
-> Queue
-> ToDevice(enp4s0f0);
ipsec_rt[2]
// Default
-> Discard;

When traffic(from FastUDPSource element) inserts in the click configuration I took the following warning but I don't know what does it really means.

expensive packet

I m kindly asking you for some input,

@ahenning
Copy link

ahenning commented Jan 4, 2021

https://pdos.csail.mit.edu/pipermail/click/2007-April/005780.html

It means there was not enough headroom (available space) to insert the headers. The default headroom is 28 bytes, which is probably being used by the UDPIPencap so when the EtherEncap wants to add another header in front of the packet, there is no free space.

I have not tried this, but you could try recompiling click after changing the default headroom to say 48 bytes in 'include/click/packet.hh'

@p4pe
Copy link
Author

p4pe commented Jan 4, 2021

I imagined that such a thing would be the cause.

Does this affects the IPSec functionality?
And by this I mean, does this affects the throughput at the sink?

@tbarbette
Copy link
Collaborator

This does not affect the functionality but certainly kills the throughput.

You can use the HEADROOM argument of FromDevice to allocate more headroom to incoming packets.

Alternatively, DPDK packets come with 128 bytes of Headroom and it will be much faster too.

@p4pe
Copy link
Author

p4pe commented Jan 4, 2021

Thank you @tbarbette.

May I ask you a question, is it wrong for IPSec functionality if i don't use the UDPIPEncap and EtherEncap and have something like this?

ipsec_rt[1]
-> IPsecESPEncap()
-> IPsecAuthHMACSHA1(0)
-> IPsecAES(1)
-> Queue
-> ToDevice(enp4s0f0);

@tbarbette
Copy link
Collaborator

Never used IPsec, sorry.

@p4pe
Copy link
Author

p4pe commented Jan 11, 2021

The HEADROOM argument seems to be working. The warning stop.

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

No branches or pull requests

3 participants