33 it is! I'm going to consider this patch reviewed.
Ethan On Thu, Sep 15, 2011 at 17:11, Jesse Gross <je...@nicira.com> wrote: > I don't really think this all that important. Neither moving the > range that we allocate from nor making it discontinuous is that hard. > Like I said before, I don't really care that much. 33 is fine. > > On Thu, Sep 15, 2011 at 5:06 PM, Ben Pfaff <b...@nicira.com> wrote: >> I can't argue with that. We could add a way to query it, I guess, if >> really necessary. >> >> On Thu, Sep 15, 2011 at 05:04:16PM -0700, Jesse Gross wrote: >>> I meant moving the group of fallback IDs would break things. >>> >>> On Thu, Sep 15, 2011 at 5:01 PM, Ben Pfaff <b...@nicira.com> wrote: >>> > It wouldn't break the ABI to move either pool around, because those >>> > aren't hardcoded in userspace, only in the kernel. ??A discontinuous >>> > range would also work but wouldn't be necessary. >>> > >>> > On Thu, Sep 15, 2011 at 04:55:56PM -0700, Jesse Gross wrote: >>> >> I guess the other thing is if we want to increase our pool of >>> >> preallocated multicast groups, we have to either break the ABI or make >>> >> the current pool discontinuous. >>> >> >>> >> On Thu, Sep 15, 2011 at 4:48 PM, Ben Pfaff <b...@nicira.com> wrote: >>> >> > Personally I'd suggest 33 for this one and increment for each >>> >> > succeeding family. ??No one's ever mentioned a problem with our use of >>> >> > genetlink groups. ??Since RHEL5 is probably declining rather than >>> >> > increasing in deployment, my guess is that no one ever will. >>> >> > >>> >> > On Thu, Sep 15, 2011 at 04:44:53PM -0700, Jesse Gross wrote: >>> >> >> Not really, I don't have any particular opinion on the actual number. >>> >> >> The only thing that I was concerned about is what it would look like >>> >> >> if we want to do this with the multicast groups for other families. >>> >> >> >>> >> >> On Thu, Sep 15, 2011 at 4:40 PM, Ethan Jackson <et...@nicira.com> >>> >> >> wrote: >>> >> >> > Based on my offline discussions with Jesse I arrived, rather >>> >> >> > arbitrarily, at the number 214. ??I don't know enough about the >>> >> >> > kernel >>> >> >> > to judge what a good number choice would be. ??Jesse seemed to think >>> >> >> > larger was better. ??I'll use whatever the two of you think is best. >>> >> >> > >>> >> >> > Ethan >>> >> >> > >>> >> >> > >>> >> >> > On Thu, Sep 15, 2011 at 16:31, Ben Pfaff <b...@nicira.com> wrote: >>> >> >> >> On Thu, Sep 15, 2011 at 04:10:55PM -0700, Ethan Jackson wrote: >>> >> >> >>> > Where does the number 214 come from? >>> >> >> >>> >>> >> >> >>> Experimentally I found that the number had to be fairly small. ??I >>> >> >> >>> wanted it to be large enough to be unlikely conflict to values the >>> >> >> >>> proper way. ??I also wanted a number which was arbitrary to avoid >>> >> >> >>> conflicting with other people who may be improperly hardcoding >>> >> >> >>> values >>> >> >> >>> like this. >>> >> >> >> >>> >> >> >> We already use genetlink groups 16 through 31 (see >>> >> >> >> datapath/linux/compat/genetlink-openvswitch.c) and group 32 (see >>> >> >> >> datapath/linux/compat/genetlink-brcompat.c). ??I don't think it >>> >> >> >> makes >>> >> >> >> sense to skip all the way to 214. ??Even in 2.6.37 I only see a >>> >> >> >> total >>> >> >> >> of 11 defined genetlink multicast groups, so I doubt that anyone's >>> >> >> >> going to backport a bunch of them to RHEL 5. >>> >> >> >> >>> >> >> > >>> >> > >>> > >> > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
