On Fri, Aug 12, 2016 at 9:29 PM, Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
[...]
>> +static bool range_in_ranges(struct net_range *r, struct net_ranges *rs)
>> +{
>> + int ri;
>> +
>> + for (ri = 0; ri < rs->num_entries; ri++)
>> + if (r->min_value >= rs->range[ri].min_value &&
>> + r->max_value <= rs->range[ri].max_value)
>> + return true;
>> +
>> + return false;
>> +}
>> +
>> +/* Returns true if all the ranges in rs1 are subsets of at least one of the
>> + * ranges in rs2, ans returns false otherwise.
>> + */
>> +static bool ranges_in_ranges(struct net_ranges *rs1, struct net_ranges *rs2)
>> +{
>> + int ri;
>> +
>> + for (ri = 0; ri < rs1->num_entries; ri++)
>> + if (!range_in_ranges(&rs1->range[ri], rs2))
>> + return false;
>> +
>> + return true;
>> +}
>
> This is not a scalable implementation. The next step would be to
> do a binary search, hash table or something else here?
> I think the root of the problem is in hard coded checks
> that quickly become inefficient and inadequate as applicability
> of the feature grows.
> We already have BPF that can suite this purpose much better
> without bloating the kernel code with parsing and matching logic.
>
This is not a per packet cost and mostly paid once when you are
establishing the channel. Having said that I do agree with you that
the check can be optimized by doing something like a hash-table etc.
This is an ABI extension to the cgroup so having the code where it is
now makes sense to maintain that ABI compatibility. Implementing using
something else (e.g. eBPF etc.) would just mean that this code needs
to be just moved at a different place than the current place so the
net gain would be nothing.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
