net: reserve ports for applications using fixed port
in [Kernel]
|
Prev: vfs: don't call ima_file_check() unconditionally in nfsd_open()
Next: Allow CONFIG_MIGRATION to be set without CONFIG_NUMA or memory hot-remove
From: Eric W. Biederman on 16 Feb 2010 12:30 Octavian Purdila <opurdila(a)ixiacom.com> writes: > This iteration makes the bitmap dynamically allocated since it is > quite big (8192 bytes) and adding that much in BSS may still, > apparently, cause problems on some architectures. > > > Octavian Purdila (3): > sysctl: refactor integer handling proc code > sysctl: add proc_dobitmap > net: reserve ports for applications using fixed port numbers > I don't like the /proc interface for this. That is certainly not the format I would choose for a bitmap. The way you have described this it looks like you are a set of different individual values instead of one large value. History says one value per file is the ideal in a user space facing interface. Intuitively I would not know how to change your new proc interface after catting the file. The classic read the file tweak the value and write the new value back will not work. Also we already have a common function for dealing with bitmaps in /proc. bitmap_parse_user. Used in /proc/irq/NNN/smp_affinity among other places. So can you please use bitmap_parse_user, or break this up into 64k individual files that we can set individually? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Octavian Purdila on 16 Feb 2010 13:10 On Tuesday 16 February 2010 19:25:04 you wrote: > I don't like the /proc interface for this. That is certainly not the > format I would choose for a bitmap. The way you have described this > it looks like you are a set of different individual values instead of > one large value. History says one value per file is the ideal in a > user space facing interface. Intuitively I would not know how to > change your new proc interface after catting the file. The classic > read the file tweak the value and write the new value back will not > work. > > Also we already have a common function for dealing with bitmaps > in /proc. bitmap_parse_user. Used in /proc/irq/NNN/smp_affinity > among other places. > > So can you please use bitmap_parse_user, or break this up into > 64k individual files that we can set individually? > Hi Eric, thanks for going over this. The use case (large bitmaps/lists) is different enough from what we have today (small bitmaps) and that is why I think that we need this new interface. If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K comma separated values. That is not the most intuitively way for the user to set a list of ports he wants to reserve. Using 64K files has the same practical issues (the user would have to cat all 64K files to determine which ports are reserved) plus it has issues caused by the large number of files: significant memory overhead and also significant time for registering those files. If this new interface is unacceptable I would rather go with a setsockopt approach, since either of the above approaches are more like machine friendly instead of user friendly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 16 Feb 2010 13:50 Octavian Purdila <opurdila(a)ixiacom.com> writes: > Hi Eric, thanks for going over this. > > The use case (large bitmaps/lists) is different enough from what we have today > (small bitmaps) and that is why I think that we need this new interface. > > If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K comma > separated values. That is not the most intuitively way for the user to set a > list of ports he wants to reserve. In this case I expect an interface of comma separated ranges would be ideal. Typically compact, and modifiable by writing the new value to the file. I think the default value would be something like 32768-61000. > Using 64K files has the same practical issues (the user would have to cat all > 64K files to determine which ports are reserved) plus it has issues caused by > the large number of files: significant memory overhead and also significant time > for registering those files. "grep -l 1 *" isn't particularly difficult, and it would be one sysctl registration call. It is true that the sysctl memory footprint would be a pain in that case. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Octavian Purdila on 16 Feb 2010 15:00 On Tuesday 16 February 2010 20:49:37 you wrote: > > The use case (large bitmaps/lists) is different enough from what we have > > today (small bitmaps) and that is why I think that we need this new > > interface. > > > > If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K > > comma separated values. That is not the most intuitively way for the > > user to set a list of ports he wants to reserve. > > In this case I expect an interface of comma separated ranges would be > ideal. Typically compact, and modifiable by writing the new value to > the file. > Something like bellow? # set bits 8080 and 1666 $echo 8080 1666-1666 > /proc #reset bit 1666 $echo 8080 > /proc #reset whole bitmap $echo > /proc > I think the default value would be something like 32768-61000. Note that this new proc entry will work in conjunction with the existing ip_local_port_range option, so the default bitmap can (and should be) empty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 16 Feb 2010 15:10
Octavian Purdila <opurdila(a)ixiacom.com> writes: > On Tuesday 16 February 2010 20:49:37 you wrote: > >> > The use case (large bitmaps/lists) is different enough from what we have >> > today (small bitmaps) and that is why I think that we need this new >> > interface. >> > >> > If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K >> > comma separated values. That is not the most intuitively way for the >> > user to set a list of ports he wants to reserve. >> >> In this case I expect an interface of comma separated ranges would be >> ideal. Typically compact, and modifiable by writing the new value to >> the file. >> > > Something like bellow? > > # set bits 8080 and 1666 > $echo 8080 1666-1666 > /proc > > #reset bit 1666 > $echo 8080 > /proc > > #reset whole bitmap > $echo > /proc Yes. So something like that. I think I would use commas instead of spaces as that is more traditional. >> I think the default value would be something like 32768-61000. > > Note that this new proc entry will work in conjunction with the existing > ip_local_port_range option, so the default bitmap can (and should be) empty. Do we want userspace to see this implementation detail? Two data structures doing the almost the same thing could get confusing in a hurry. It feels like a recipe for changing one and not the other and then running around trying to figure out why the change did not work. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |