4 ms·

Nokia, ARM, Enea craft new TCP/IP stack for the cloud

48 points by timthorn 11y ago

rzzzt 11y ago
There's a link to the actual project in the article; the technical overview page gives a reasonable summary of the components [1]. Looks like it relies on another, lower level API, called OpenDataPlane [2]. [1] http://www.openfastpath.org/index.php/service/technicaloverview/ http://www.openfastpath.org/index.php/service/technicaloverv... [2] http://www.opendataplane.org/about/ http://www.opendataplane.org/about/
api 11y ago
Andrew Tenenbaum, thou art avenged! Seeing a lot of this these days.
- pjmlp 11y ago
  He is already avenged, as the majority of real time OS and embedded systems use micro-kernels.
jedisct1 11y ago
What does "for the cloud" even mean? Previous TCP/IP stacks were not able to connect to someone else's computer?
- ZenoArrow 11y ago
  The article suggests that we're looking at a faster TCP/IP stack, with the increased performance based in part on custom hardware. The only real link to the cloud is that cloud hosts are seen as its target market.
- cgh 11y ago
  "Better suited for the cloud" would probably be better. It looks like it's meant to work with OpenDataPlane. In general, it's another piece in the puzzle of providing heterogenous compute resources without a reliance on a specific kernel or operating system.
walterbell 11y ago
> They say the stack is optimised for OpenDataPlane (ODP) programming interfaces. This will let OpenFastPath take advantage of acceleration in systems-on-a-chip that support ODP, and make the protocol programmable via the ODP environment. Are those SoCs optimised for line rate packet processing / DPI?
- virtuallynathan 11y ago
  There are some, stuff like the Freescale LS2085A, Cavium ARM chips, etc. They have networking / ODP offload capabilities.
mschuster91 11y ago
Hmm. Shouldn't the data packets arrive in kernel space at the beginning (in the HW driver, or if the driver is implemented in userspace, the PCIe-bus driver in the kernel) - thus making at least one context switch to userspace (with copying the packet, possibly) neccessary? A full-kernel TCP/IP stack should not need to leave kernelspace or copy stuff around, except when passing control to the userland application.
- joshAg 11y ago
  The idea is to allow user space direct access to the necessary buffers, so there's no user/system copying or context switching.

48 points by timthorn 11y ago

rzzzt 11y ago

There's a link to the actual project in the article; the technical overview page gives a reasonable summary of the components [1]. Looks like it relies on another, lower level API, called OpenDataPlane [2]. [1] http://www.openfastpath.org/index.php/service/technicaloverview/ http://www.openfastpath.org/index.php/service/technicaloverv... [2] http://www.opendataplane.org/about/ http://www.opendataplane.org/about/

api 11y ago

Andrew Tenenbaum, thou art avenged! Seeing a lot of this these days.

pjmlp 11y ago
He is already avenged, as the majority of real time OS and embedded systems use micro-kernels.

jedisct1 11y ago

What does "for the cloud" even mean? Previous TCP/IP stacks were not able to connect to someone else's computer?

ZenoArrow 11y ago
The article suggests that we're looking at a faster TCP/IP stack, with the increased performance based in part on custom hardware. The only real link to the cloud is that cloud hosts are seen as its target market.
cgh 11y ago
"Better suited for the cloud" would probably be better. It looks like it's meant to work with OpenDataPlane. In general, it's another piece in the puzzle of providing heterogenous compute resources without a reliance on a specific kernel or operating system.

walterbell 11y ago

> They say the stack is optimised for OpenDataPlane (ODP) programming interfaces. This will let OpenFastPath take advantage of acceleration in systems-on-a-chip that support ODP, and make the protocol programmable via the ODP environment. Are those SoCs optimised for line rate packet processing / DPI?

virtuallynathan 11y ago
There are some, stuff like the Freescale LS2085A, Cavium ARM chips, etc. They have networking / ODP offload capabilities.

mschuster91 11y ago

Hmm. Shouldn't the data packets arrive in kernel space at the beginning (in the HW driver, or if the driver is implemented in userspace, the PCIe-bus driver in the kernel) - thus making at least one context switch to userspace (with copying the packet, possibly) neccessary? A full-kernel TCP/IP stack should not need to leave kernelspace or copy stuff around, except when passing control to the userland application.

joshAg 11y ago
The idea is to allow user space direct access to the necessary buffers, so there's no user/system copying or context switching.