Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> On Mon, Nov 12, 2012 at 01:47:05PM +0100, Florian Westphal wrote:
> > Alternative would be to keep track of highest bit requested in a "-m connlabel"
> > rule to figure out the needed size.
> >
> > In any case, it would require adding "u16 len" to the extension area; else
> > we can't figure out how many bytes are valid, i.e.:
> >
> > struct nf_conn_labels {
> > + u16 size; /* length of label storage */
> > + unsigned long bits[]; /* variable-sized label storage */
> > +};
> >
> > it would increase minimum length needed but it would avoid
> > the rcu dances done by the current scheme.
> >
> > It this is ok for you I'll make this change to see how many LOC are
> > saved by this.
>
> If we simplify the current connlabel code it would be great. And so
> far, the only way I can think to obtain that is to explictly specify
> via the CT target the length of the label.
I've turned it into a var-length extension, so all the rcu dances
and runtime reallocs are gone.
I'll be sending the first non-rfc version of the patchset soon.
Minor drawback: I had to reduce it to 128 labels max, else the
extension offset array (u8 offset[]) will overflow if too many
extensions are enabled.
At the moment the 128 labels max constraint is no problem at all,
and we can increase it later if we reduce total possible extension
size (or use u16 for length/offset tracking).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
