Date: Fri, 16 Mar 2012 20:22:45 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-net@freebsd.org Subject: Re: netmap Message-ID: <CAD2Ti28W3JoBEyBqzkRkTzPh2VhmT3bM9EYe1-NnSFbaPXzHDg@mail.gmail.com> In-Reply-To: <20120316231337.GA62350@onelab2.iet.unipi.it> References: <CAD2Ti2-%2BRQZA8Tx6F746k%2Bz01yztZcKYUoptCYwFsp7odffExw@mail.gmail.com> <20120316231337.GA62350@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> yes this is the long term plan (actually, kind of works now too > if the netmap-attached client then passes the packets to the host > stack). I would not know how to do that as a common user. Maybe like divert/natd socket in ipfw. But perhaps natd is the only example of user tool in base for that kind of thing right now. > The tricky question is who select which (incoming) traffic needs > to go to the host, and which one should be filtered out. I have > some ideas but need to figure out what is the best way to go. I guess it would need to have all the usual interface semantics... MAC, multicast, promiscuous, alias, vlan, jumbo, v4/v6, checksum, routing, bpf, statistics. I doubt userland interface for all those to the kernel exists yet, and some are only accessible by the code nearest the iron. Maybe better to let the full emulator be kernel space. And it seems there is some additional configuration, or loss of service risk, if the emulator is userland and that account gets compromised. If that is what you meant by 'who'. If the user wanted to then run divert/natd, raw, quagga, and other processing for read/write, they could as normal, just with net0 interface. Anyways, I don't know much. > the em family is already supported. For the 100Mbit ports there > is really no point, as CPUs are fast enough already. Of course, it would just be a consistency thing, /dev/netmap ed0 :) And much boring work when 1000Mbit parts is cheap standard to use now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti28W3JoBEyBqzkRkTzPh2VhmT3bM9EYe1-NnSFbaPXzHDg>