Michael Hunter wrote:
On Tue, 04 Apr 2006 11:48:39 -0400
Dan Groves <[EMAIL PROTECTED]> wrote:
Hello all,
As part of project Clearview
(http://www.opensolaris.org/os/project/clearview/), we are updating
snoop so that it can filter VLAN tagged packets. I've posted a design
document and some background information to:
http://www.opensolaris.org/os/project/clearview/vlan_filtering/
As work progresses, I'll update the page with any man page changes,
PSARC cases, or other pertinent documentation.
Any comments you have on what is available would be appreciated.
Nice set of documents. Some questions below. The only serious
one is #3.
My first two comments on really on the recommendations document
referred to by the detailed design:
1) 4.2 paragraph 3 you state that "but will not improve performance"
referring to adding indirectly to pfmod. I would have expected that
program which used the new indirection support would have seen
performance improvement over doing it in user space.
Yes, adding indirection to pfmod allows more programs to execute in
kernel space. However, for this change, we're only taking advantage of
indirection so that snoop can check for a VLAN tag. We're not going to
move anything from user space to kernel space (i.e. anything that is
filtered in user space before the change will still be filtered in user
space, and anything filtered in kernel space before the change will
still be filtered in kernel space after the change).
2) Section 2 right before the end states that "Snoop does have
optimizations where it will try and break filter expressions..."
But section 4.5 makes the statement that breaking expressions
up in general would be difficult. I agree with the second
statement although if the only reason you couldn't do the
optimizations was schedule then I think it would make sense to
do the thing that would give you the best chance for maximal
performance in the long run and leave the implementation to
future generations. In any case thats probably moot. You
want to waste as few cycles on the packets you are going to
throw away as possible.
I do have some ideas for optimizations to reduce the impact of my
changes. I haven't worked on them in a while because I've been trying
to get the initial changes done and make sure they're correct.
What I had in mind with the high level recommendations document in
section 4.5 was to come up with more intelligent ways of getting rid of
unwanted packets in kernel space when the expression requires user space
filtering. What's in snoop right now is pretty simplistic.
design document:
3) OK, I bite. Why no simple way to reference the vlan id?
You add the ability to do something useful and then claim
no requirement to make it easy to use?
Yes. The requirements were to make snoop be able to filter VLAN tagged
packets. If there's time to do so, and there's a desire for this
feature, I can add functionality to make it easy for the user to filter
on a VLAN id.
4) No support for VLAN stacking seems fine given lack of
general support but is there anything in your design that
precludes from adding it simply in the future?
I don't think so, as long as implementations don't stack an arbitrary
number of VLAN tags on top of each other. The ideal way (and probably
only) way to support that is to have looping support in the packet
filtering language. BPF doesn't have it for the reason that someone
might put a program running in kernel space in an infinite loop. You
could do things like put in a loop counter, but then how do you adjust
it in a way that doesn't effectively allow a hacker to do the same
thing? A big can of worms.
5) section 3.4 and this is probably what you really meant
by the statemnt in 4.2 in the other document.
Sorry, I don't understand. Are you commenting about performance or not
affecting other users of pfmod?
Thanks for the comment!
Dan
mph
thanks,
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
