From: Nikolay Aleksandrov
Date: Tue, 12 Dec 2017 16:02:50 +0200
> Before this patch the bridge used a fixed 256 element hash table which
> was fine for small use cases (in my tests it starts to degrade
> above 1000 entries), but it wasn't enough for medium or large
> scale deployments. Modern set
On 12/12/17 20:02, Stephen Hemminger wrote:
> On Tue, 12 Dec 2017 16:02:50 +0200
> Nikolay Aleksandrov wrote:
>
>> +memcpy(__entry->addr, f->key.addr.addr, ETH_ALEN);
>
> Maybe use ether_addr_copy() here?
>
This is an unrelated cleanup, the code in question was already like that. I
On 12/12/17 20:07, Stephen Hemminger wrote:
> On Tue, 12 Dec 2017 16:02:50 +0200
> Nikolay Aleksandrov wrote:
>
>> Before this patch the bridge used a fixed 256 element hash table which
>> was fine for small use cases (in my tests it starts to degrade
>> above 1000 entries), but it wasn't enough
On Tue, 12 Dec 2017 16:02:50 +0200
Nikolay Aleksandrov wrote:
> Before this patch the bridge used a fixed 256 element hash table which
> was fine for small use cases (in my tests it starts to degrade
> above 1000 entries), but it wasn't enough for medium or large
> scale deployments. Modern setup
On Tue, 12 Dec 2017 16:02:50 +0200
Nikolay Aleksandrov wrote:
> + memcpy(__entry->addr, f->key.addr.addr, ETH_ALEN);
Maybe use ether_addr_copy() here?
Before this patch the bridge used a fixed 256 element hash table which
was fine for small use cases (in my tests it starts to degrade
above 1000 entries), but it wasn't enough for medium or large
scale deployments. Modern setups have thousands of participants in a
single bridge, even only enabling