On Fri, Sep 18, 2020 at 05:32:41PM +0100, Mark Gray wrote: > On 18/09/2020 15:33, Mark Gray wrote: > > On 17/09/2020 20:23, Flavio Leitner wrote: > >> On Thu, Sep 17, 2020 at 08:43:38PM +0200, Ilya Maximets wrote: > >>> On 9/9/20 7:08 PM, Mark Gray wrote: > >>>> From: Aaron Conole <[email protected]> > > > >>> What is the reason of having this pool? Datapath port numbers are unique > >>> except for ODPP_NONE, and all the functions you implemented actually > >>> iterates over all channels anyway to find one with requested port_idx. > >>> So, the only purpose of it is to avoid searching on incorect port number, > >>> but this should be a rare case. Can we just remove it? > >>> > >>> OTOH, if it's necessary to have this id pool, I'd suggest to use hmapx > >>> instead as it already has all required infrastructure and doesn't actually > >>> care about range of values. > >> > >> Well, now it iterates over handlers looking for a channel that has > >> a port, so maybe it's better to have ports hashed so we can get the > >> channel? > > > > So each channel will be in two maps, one global one for fast searches > > and to check for duplicates and a per-handler one? > > > > I will make this change. It will be a significant rework but I think it > will make a different to the efficiency and clarity of the code.
I suggested that based on how the code is using the objects, but I haven't exercised the idea enough to say if the solution will look ok in the end. Thanks, -- fbl _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
