Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54966

User-space networking

Show all headers | View raw

I found the following article interesting:

<https://lwn.net/Articles/713918/>

The Snabb networking toolkit described in the article is written using
LuaJIT, but the problem looks like it would be a good fit for Forth,
and there are some other Forth-related aspects here.

The problem is that they have so many packets to process that going
through the kernel for network access is too slow.  So they apparently
memory-map the network cards' control registers to user space, and
access them directly; and of course the network cards put the data
they reveive in buffers in user space (in L3 cache according to the
article), and get the data they receive from user space.  Only basic
functionality of the network cards is used, not advanced,
highly-touted, and often buggy features like TCP offload engines.
There is little processing time available per packet, so the
processing code cannot be very long.

That's an environment much like the original Forth setup: direct
hardware access without intervening kernel, and performance counts.
so this is an area where Forth could be used profitably.  Of course,
they already have a quick-development solution using LuaJIT, and if
that's not good enough for performance, they will probably drop down
into C or assembly language, so Forth probably cannot get into this
area, but anyway, this shows that the place of Forth is not just in
small embedded controllers with little RAM.

The philosophy they use is also pretty Forthy:

|The idea behind Snabb, he said, is "rewritable software" — as in "I
|could rewrite that in a weekend".
[...]
| Snabb was built around a set of three simple design principles:
|
|    Simple > Complex
|    Small > Large
|    Commodity > Proprietary 
[...]
|For small: the original Snabb implementation had a code budget. Snabb
|as a whole was meant to be less than 10,000 lines of code and build in
|less than one minute. These constraints, it was hoped, would lead to
|problems being solved in a creative way.
[...]
|To stay small, Snabb also avoids depending on big projects. Rather
|than use the DPDK drivers, Snabb's developers have written their own.

The original Forth environments had memory and CPU limits that
enforced the kind of creativity that the Snabb people enforce with
their code-size and build-time limit (I wonder why 10,000 lines of
code take one minute to build, though).

The third Forth tangent is net2o.  AFAIK, currently net2o is tunneling
over UDP/IP, but I think the idea is to eventually have the routers
understand net2o and route it directly.  If the processing is moving
from special-purpose hardware into easily malleable software like
Snabb, it seems that getting direct net2o routing could be much
easier, and therefore could be introduced much faster than I expected
before.  Does that mean that the routers will be programmed in Forth?
Not necessarily.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

Back to comp.lang.forth | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

User-space networking anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-18 07:53 +0000
  Re: User-space networking lukego@gmail.com - 2017-02-19 03:42 -0800
    Re: User-space networking foxaudioresearch@gmail.com - 2017-02-19 06:44 -0800
  Re: User-space networking polymorph self <jackvanc3@gmail.com> - 2017-02-21 08:54 -0800
  Re: User-space networking polymorph self <jackvanc3@gmail.com> - 2017-03-01 12:01 -0800

csiph-web