|
Lewis Donzis
11/15/2007 12:23 PM
post2660
|
Our products are based on the io-net filter modules we've developed, and so far we've been unable to find any way to
accomplish the same functionality in the new architecture. We rely on the ability to filter packets seen by virtue of
an interface being in promiscuous mode, and to keep them from ever reaching the stack (by either dropping them or
sending them out another interface). The BPF interface would let us see the packets, but not drop them, and would also
probably be too slow (speed is critical in our applications). The Packet Filter interface doesn't appear to be able to
pass us anything not addressed to our own MAC address. With io-net we had a nice way to intercept traffic and pass it
up the stack, redirect it to another interface, or drop it. We currently see no way to implement our products with io-
pkt!
Murf
|
|
|
|
|
|
Robert Craig
11/15/2007 2:19 PM
post2661
|
Hi Murf:
Just to let you know, we're cogitating on this one. There is indeed a tap point where this sort of functionality can
be provided, but we're thinking (well... OK. SEAN is thinking :>) about the "best" way to provide access to it.
Robert.
|
|
|
|
|
|
John Murphy
11/15/2007 11:33 PM
post2670
|
Great! Glad to hear about the cogitation. Ideally, we'd like to be able to insert ourselves between the Ethernet
driver and the ether_input() function, with no intervening lookups to see which which module or modules get the packet -
-- much as if we were to replace pfil_run_hooks() and provide that level of functionality ourselves. Actually,
pfil_run_hooks() doesn't look like it adds that much overhead, but speed is crucial for us --- and I did say "ideally".
Thanks for looking into it!
Murf
|
|
|
|
|
|
Xiaodan Tang(deleted)
11/16/2007 10:11 AM
post2681
|
You can add/register a pfil_hooks, and let phil_run_hooks() call you.
Then you can decided drop it, let through. For sending it out on a perticular interface, I think you can just find out
the ifp, and call ifp->if_output() on it ?
The only problem here, is pfil_run_hooks() doesn't get run if its a M_PROMISC packet. There doesn't seems a way to
around it :(
|
|
|
|
|
|
Xiaodan Tang(deleted)
11/16/2007 10:18 AM
post2682
|
> Great! Glad to hear about the cogitation. Ideally, we'd like to be able to
> insert ourselves between the Ethernet driver and the ether_input() function,
> with no intervening lookups to see which which module or modules get the
> packet --- much as if we were to replace pfil_run_hooks() and provide that
> level of functionality ourselves. Actually, pfil_run_hooks() doesn't look
> like it adds that much overhead, but speed is crucial for us --- and I did say
> "ideally".
On another thought, "Ideally" :)
You can modify ether_ifattach() yourself, to hook_up your own if_input() function (instead of ether_input).
Or, if you don't like the idea to modify io-pkt, you can have your own filter module comming in, scan the iflist, and
modify ifp->if_input to point to your own input function?
There might be racing window to watch out though. You probably want to turn down the interface while you modify the
function pointer.
|
|
|
|
|
|
Sean Boudreau(deleted)
11/16/2007 11:01 AM
post2690
|
On Fri, Nov 16, 2007 at 10:18:52AM -0500, Xiaodan Tang wrote:
> > Great! Glad to hear about the cogitation. Ideally, we'd like to be
> able to
> > insert ourselves between the Ethernet driver and the ether_input()
> function,
> > with no intervening lookups to see which which module or modules get
> the
> > packet --- much as if we were to replace pfil_run_hooks() and provide
> that
> > level of functionality ourselves. Actually, pfil_run_hooks() doesn't
> look
> > like it adds that much overhead, but speed is crucial for us --- and I
> did say
> > "ideally".
>
> On another thought, "Ideally" :)
>
> You can modify ether_ifattach() yourself, to hook_up your own if_input()
> function (instead of ether_input).
>
> Or, if you don't like the idea to modify io-pkt, you can have your own
> filter module comming in, scan the iflist, and modify ifp->if_input to
> point to your own input function?
>
> There might be racing window to watch out though. You probably want to
> turn down the interface while you modify the function pointer.
I think the easiest way to provide the same functionality
is to set up a struct pfil_head that's walked (ie: pfil_run_hooks())
first thing on ether_input(). This way filters can be chained
as opposed to stacked in io-net. There is the per interface
pfil hook ((struct ifnet *)->if_pfil) that's walked later in
ether_input() but as you mentioned it isn't passed
promiscuous packets and you'd have to register on each
interface to get all packets.
Something like the attached diff?
-seanb
|
|
|
|
|
|
John Murphy
11/16/2007 11:20 AM
post2694
|
Sean, the new PFIL hook also sounds like a great idea. I still don't relish the thought of all the work it's going to
take to rework all our filters and Ethernet drivers, but at least now the task sounds possible.
Thanks!!!
Murf
|
|
|
|
|
|
Robert Craig
11/16/2007 12:58 PM
post2703
|
You can, of course, keep using your existing io-net drivers with the shim, but I'm guessing that your reason for a re-
write would be to get the extra receive performance our of your driver.
On another thought, if these packets aren't actually working their way up the IP stack, it might not be as important
to re-do the drivers. The largest performance gain comes from the fact that there isn't any thread context switching
between the receive thread and the stack thread. If you're doing all of your processing of packets in layer 2, I
wouldn't expect to see as dramatic a performance boost over io-net.
|
|
|
|
|
|
John Murphy
11/16/2007 1:07 PM
post2704
|
> You can, of course, keep using your existing io-net drivers with the shim, but
> I'm guessing that your reason for a re-write would be to get the extra
> receive performance our of your driver.
>
> On another thought, if these packets aren't actually working their way up
> the IP stack, it might not be as important to re-do the drivers. The largest
> performance gain comes from the fact that there isn't any thread context
> switching between the receive thread and the stack thread. If you're doing
> all of your processing of packets in layer 2, I wouldn't expect to see as
> dramatic a performance boost over io-net.
>
We may decide to continue to use io-net as long as possible, since, as you point out, there doesn't seem to be any
promise of increased performance in our case, and we might even take a performance hit either in the shim or in the PFIL
overhead. Basically, we're concerned about the possibility of io-net "going away" in the future, and just trying to
understand all our options so that we can make optimum use of our limited manpower.
Murf
|
|
|
|
|
|
Sean Boudreau(deleted)
11/27/2007 10:41 AM
post2970
|
On Fri, Nov 16, 2007 at 11:20:28AM -0500, John Murphy wrote:
> Sean, the new PFIL hook also sounds like a great idea. I still don't
> relish the thought of all the work it's going to take to rework all our
> filters and Ethernet drivers, but at least now the task sounds possible.
>
The discussed pfil hook is now in.
-seanb
|
|
|
|
|
|
John Murphy
11/27/2007 7:12 PM
post3004
|
Great! Thanks again.
Murf
|
|
|
|
|
|
John Murphy
11/16/2007 11:05 AM
post2691
|
Oooh, I hadn't thought about modifying ifp->if_input! That sounds like it may be exactly what we need. Nice idea --- I
wish I'd thought of that!
Murf
|
|
|
|
|
|
