Re: [Bridge] [PATCH net-next] net: bridge: use rhashtable for fdbs

2017-12-12 Thread Nikolay Aleksandrov
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

Re: [Bridge] [PATCH net-next] net: bridge: use rhashtable for fdbs

2017-12-12 Thread Nikolay Aleksandrov
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

Re: [Bridge] [PATCH net-next] net: bridge: use rhashtable for fdbs

2017-12-12 Thread Stephen Hemminger
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 >

Re: [Bridge] [PATCH net-next] net: bridge: use rhashtable for fdbs

2017-12-12 Thread Stephen Hemminger
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?

[Bridge] [PATCH net-next] net: bridge: use rhashtable for fdbs

2017-12-12 Thread Nikolay Aleksandrov
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