lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 12 Dec 2016 15:03:12 -0500 From: Vivien Didelot <vivien.didelot@...oirfairelinux.com> To: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com> Cc: Volodymyr Bendiuga <valdr.linuxnext@...il.com>, Volodymyr Bendiuga <volodymyr.bendiuga@...il.com>, netdev@...r.kernel.org, Volodymyr Bendiuga <volodymyr.bendiuga@...termo.se> Subject: Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries Hi Andrew, Andrew Lunn <andrew@...n.ch> writes: > Humm, it looks like we are doing the atu_get wrong. We are looking for > a specific MAC address. Yet we seem to be walking the whole table to > find it, rather than getting the hardware to do the search. We are not doing it wrong, the hardware does the search. A classic dump of an ATU database consists of starting from the broadcast address ff:ff:ff:ff:ff:ff and issuing GetNext operation until we reach back the broadcast address. Only addresses in used are returned by GetNext, thus dumping an empty database is completed in a single operation. I implemented atu_get intentionally this way because it provides simpler code, rather than doing arithmetic on MAC addresses (Unless I am unaware of simple increment/decrement code.) > The current code is: > > static int mv88e6xxx_atu_get(struct mv88e6xxx_chip *chip, int fid, > const u8 *addr, struct mv88e6xxx_atu_entry *entry) > { > struct mv88e6xxx_atu_entry next; > int err; > > eth_broadcast_addr(next.mac); > > err = _mv88e6xxx_atu_mac_write(chip, next.mac); > > We should be setting next.mac to one less than the address we are > looking for. > > Volodymyr, please could you try that, and see how much of a speed up > you get. > > There is another optimization which can be made. We only say there is > no such entry once we have reached the end of the table. But it will > return the entries in ascending order. So if the entry it returned is > bigger than what we are looking for, we can immediately abort the > search and say it does not exist. However your two suggestions to optimize the lookup are correct. It'd be interesting to see if that makes a significant difference or not. Thanks, Vivien
Powered by blists - more mailing lists