On Fri, Jan 06, 2017 at 08:43:03PM +0000, Daniele Di Proietto wrote: > > > > > > On 06/01/2017 11:34, "Ben Pfaff" <[email protected]> wrote: > > >On Fri, Jan 06, 2017 at 10:59:07AM -0800, Daniele Di Proietto wrote: > >> bridge_delete_or_reconfigure() deletes every interface that's not dumped > >> by OFPROTO_PORT_FOR_EACH(). ofproto_dpif.c:port_dump_next(), used by > >> OFPROTO_PORT_FOR_EACH, checks if the ofport is in the datapath by > >> calling port_query_by_name(). If port_query_by_name() returns an error, > >> the dump is interrupted. If port_query_by_name() returns ENODEV, the > >> device doesn't exist and the dump can continue. > >> > >> port_query_by_name() for the userspace datapath returns ENOENT instead > >> of ENODEV. This is expected by dpif_port_query_by_name(), but it's not > >> handled correctly by port_dump_next(). > > > >Should port_query_by_name() for the userspace datapath return ENODEV, > >instead? > > Sorry to waste your time on this. Yes, that seems the more appropriate > solution. > > I decided to handle both ENODEV and ENOENT to be consistent with what we did > in > the past, e.g bee6b8bc16b1("dpif: Don't log warning for ENOENT with > dpif_port_exists()."). > > I suspected that ENOENT could only come from the userspace datapath, but I > wasn't > too sure about that. > > After looking at vport_cmd_get() and testing it I couldn't find any ENOENT, > so, > probably, we added all those special cases just for the userspace datapath. > > How about the following v3? > > https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327323.html
Looks good. I'm glad we got this figured out. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
