2

I have the following requirment,

I have a Linux PC connected directly to an embedded board.

The Linux PC receives IP traffic from the Internet - it needs to forward this to the embedded board. However the embedded board does not have ability to reassemble IP fragments. Currently what we do is receive the reassembled packet in the linux pc and then sendto() to the emmbeded board. However given the high load of traffic this consumes too much CPU cycles in the Linux PC - since this invovles a copy from kernel space to user space and again the same packet is copied from user space to kernel space.

Is there a way for the kernel to reassemble the fragements and IP forward it to the embedded board without the packet having to come to user space? Note: I have the flexibility to make the destination IP of the IP packets as either the Linux PC or the embedded board.

Thanks

user2637693
  • 55
  • 6
  • TCP? UDP? Other? IP reassembly takes place *in* the IP stack, not user space. If you're using TCP you can do a zero-copy transfer. – user207421 Feb 17 '14 at 23:49

2 Answers2

1

Broadly speaking, no this is not built into the kernel, particularly if your reassembled packet exceeds the MTU size and therefore cannot be transmitted to your embedded board. If you wanted to do it, I'd suggest routing via a tun device and reassembling in user space, or (if you are just using tcp) using any old tcp proxy. If written efficiently it's hard to see why a linux PC would not be able to keep up with this if the embedded board can manage to process the output. If you insist on using the kernel, I think there is a tcp splice technique (see kernel-based (Linux) data relay between two TCP sockets) though whether that works at a segment level and thus does not reassemble, I don't know.

However, do you really need it? See: http://en.wikipedia.org/wiki/Path_MTU_Discovery

Here tcp sessions are sent with the DF bit set precisely so no fragmentation occurs. This means that most such tcp sessions won't actually need to support fragmentation.

Community
  • 1
  • 1
abligh
  • 24,573
  • 4
  • 47
  • 84
  • THanks for the response. I am aware of Path MTU discovery, but this is for a particular requirement where we need TCP traffic to go with max MTU size. The Linux PC also runs other applications, hence the cpu load concern – user2637693 Feb 18 '14 at 08:17
  • I'm not sure the load will be significantly different in kernel vs user space if it's doing fragment reassembly, but it looks like you need to look at the tcp splice link above then, which as far as I know is the only way that might work in kernel space without a custom module. – abligh Feb 18 '14 at 08:28
  • Sorry I made a mistake - it was for UDP traffic that is guaranteed to come as fragments to the Linux PC. This UDP traffic I want to reassemble in the Linux PC and forward to the embedded board. (as effecient as possible) – user2637693 Feb 18 '14 at 08:46
  • OK, then I think my answer is correct (though not what you wanted to hear), i.e. the kernel cannot do this in kernel space unless you write something specific to do it. I'm assuming there's no possibility of (i) switching to tcp or (ii) transmitting the path MTU size (as discovered with a dummy TCP session) to the client so the client can always arrange the UDP packets are smaller than that, or (iii) using UDP packets that are guaranteed to be smaller than the the minimum IP MTU size (from memory 512 bytes but check that) – abligh Feb 18 '14 at 12:00
  • Why do you keep saying the kernel can't do it in kernel space? That's where IP reassembly happens. – user207421 Feb 18 '14 at 20:54
  • @EJP Because the kernel only reassembles IP packets if destined to the the local IP address. He wants to either reassemble and forward the packets (reassembly is not done in the forwarding pathway), or reassemble and proxy. Neither of those are supported in the kernel - unless you know different, of course! – abligh Feb 18 '14 at 21:54
0

Based on the title of the question, it appears you need to perform reassembly on the intermediate node (linux device). This doesn't mean you have to do it in the kernel space.

Take a look at DPDK. It is an opensource dataplane development kit. It may sound complicated, but all it does is use Poll Mode Drivers to get packets up to the user space with out the copying and interrupt overhead.

Please not, it uses poll mode drivers and will take up CPU cycles. You can use dpdk on a x86_64 hardware if you are ready to give up a couple of cores assuming you also want to fragment the packets in the reverse path.

Take a look at the sample application guide of DPDK for packet fragmentation and reassembly.

SuYo
  • 26
  • 3