Re: recvfrom

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 11, 2001 at 02:18:31PM -0400, Jason Lunz wrote:
> On Wed, Apr 11, 2001 at  6:44PM +0200, Andi Kleen wrote:
> > If you don't need receiving on the local box you could also do it via 
> > ethertap device or packet socket on dummy device, and then reinject into the
> > network. It'll not work for local packets though, because the routing
> > code does not allow to route locally destined packets somewhere else.
> 
> You'd still have a speed problem as well. Depending on what you're
> doing, that's two copy_(to|from)_users of the entire packet. Being able
> to combine raw packet filtering with the speed of mmapped packet sockets
> seems a good way to do this quickly, especially if you don't need to
> filter on the entire packet.

The zero copy code in vger has most of the infrastructure to do the same
with normal sockets, just the final user interface is missing.
Of course it'll never be really fast when you need to context switch to a 
process first (see old screend) 

One feature that is currently already in kernel is the SOCK_FILTER option;
you can push on every socket a LPF (slightly modified BPF) filter that
filters all packets arriving on that socket (works for TCP and UDP/RAW).
It's just per socket, not global.

> 
> I'm still not sure why it locks up on SMP at gigabit ethernet speeds,
> though.

What locks up? 


-Andi
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux