[ovs-dev] [PATCH 1/2] dpif: Update dpif interface to match netdev.

Jesse Gross jesse at nicira.com
Thu Jan 28 01:09:30 UTC 2010


Thanks for the review.  I updated it and pushed, with a few comments below:

On Fri, Jan 22, 2010 at 11:22 PM, Ben Pfaff <blp at nicira.com> wrote:

> >  int
> > -dp_enumerate(struct svec *all_dps)
> > +dp_enumerate(struct svec *names, struct svec *types)
>
> This function has a really weird interface now.  A cleaner alternative
> might be to create a dp_enumerate_types() to enumerate all the known
> types, and then a dp_enumerate_names() to enumerate the names of all the
> dps with a given type.
>
> But it seems unlikely that this function will ever be used enough to be
> annoying, so that might be overkill.
>

I ended up splitting this into dp_enumerate_types() and dp_enumerate_names()
since I'm going to want to do it in the future anyways.


> > diff --git a/lib/dpif.man b/lib/dpif.man
> > index 3a58caf..31f126a 100644
> > --- a/lib/dpif.man
> > +++ b/lib/dpif.man
> > @@ -1,11 +1,13 @@
> >  .RS
> >  .TP
> > -\fBdp\fIN\fR
> > +[\fItype\fR:]\fBdp\fIN\fR
>
> But the whole contents of this file are specific to dpif-linux.  In
> particular I wouldn't expect every dpif implementation to do this
> name-to-number translation dance.  Should we generalize the file?  Or
> should we make it specific to what actually gets built?
>

Eventually we'll probably need to generalize the file but right now both
datapath providers support the dpN syntax, so I left it alone.


>
> >  Datapath number \fIN\fR, where \fIN\fR is a number between 0 and 255,
> > -inclusive.
> > +inclusive.  If \fItype\fR is given, it specifies the datapath provider
> of
> > +\fBdp\fIN\fR, otherwise the default provider \fBsystem\fR is assumed.
> >  .TP
> > -\fIname\fR
> > +[\fItype\fR:]\fIname\fR
> >  The name of the network device associated with the datapath's local
> >  port.  (\fB\*(PN\fR internally converts this into a datapath number,
> > -as above.)
> > +as above.)  If \fItype\fR is given, it specifies the datapath provider
> of
> > +\fBname\fR, otherwise the default provider \fBsystem\fR is assumed.
>
> It looks like the changes to ovs-ofctl remove the ability to specify a
> vconn by giving the name of a datapath.  Is that correct?  It's too
> bad--that feature was really useful sometimes.  Can it be restored?
>

 I restored this - I just needed to pick a new delimiter for datapaths.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100127/6d0fa943/attachment-0003.html>


More information about the dev mailing list