[PATCH] multiple instances of ipfw(4)
Hello, from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! Comments/Feedback expected, Ermal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] multiple instances of ipfw(4)
On Mon, Jan 30, 2012 at 3:36 PM, Ivan Voras ivo...@freebsd.org wrote: On 30/01/2012 13:01, Ermal Luçi wrote: Surely i know that this is not the best way to implement generically ... probably, because it's similar to VNET... It depends on the comparison. The same argument would hold true for multiple routing tables but still they coexist. Both usages have their scopes. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! ... which is also done by VNET+JAILS. You should probably port it to VNET :) See above. Nevertheless, VNET is still not production use so ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Ermal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kqueue and note_rename
Am 25.01.2012 um 23:51 schrieb Julian Elischer: On 1/25/12 10:44 AM, Matthias Zitzen wrote: Hello list, does anybody have an idea, how to obtain the new name of a renamed file after the note_rename event is fired. I'm not very familiar with filesystem-operations. I checked the typical functions like stat or lstat, but these functions are working only with filenames. there is no real way. the new link to the inode could come from any point in the filesystem so the only way to find it would be an exhaustive search. the only information that you could return that might make any sense would be the inode number of the new parent. That would allow you to follow the '..' links and do 'pwd' in effect. I have not checked to see if that information is returned. If it isn't it might be a really nice enhancement to see if it could be added. Is there a any other method to get fileevents on FressBSD? especially with the filenames too? Matthias___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel threads inherit CPU affinity from random sibling
On Sat, Jan 28, 2012 at 8:22 AM, Attilio Rao atti...@freebsd.org wrote: Do you have a pathological test-case for it? Are you going to test the patch? Thanks, Attilio I tested the patch last night. Previously I was able to see a softclock thread preempted for over 1ms on machine where 4/8 cores were lightly loaded. With this patch I can see that the softclock threads are free to migrate cores and they no longer see long scheduling latencies. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] multiple instances of ipfw(4)
On 1/30/12 4:01 AM, Ermal Luçi wrote: Hello, from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! for this I use multiple vimages, but just as there is room for multiplt routing tables AND vimage, there is probably room for multiple firewalls AND vimage. this is a bit more in the iptables direction I guess. Comments/Feedback expected, Ermal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
