[ovs-dev] [PATCH] Prepare ground for extensions to sFlow export

[Neil McKee]

I rebased this with a "git pull --rebase upstream master; git push
--force-with-lease",  and made a 1-line correction to avoid a compiler
warning.  "make check" still succeeds.

So this is the picture now:

https://github.com/sflow/ovs/compare/openvswitch:master...master

I'm hoping this can go in.  These LACP and port-name extensions are useful
as they stand.  No need to wait for the tunnel stuff to settle.  Let me
know if you need me to do anything else.

Regards,
Neil



------
Neil McKee
InMon Corp.
http://www.inmon.com


On Tue, Jul 15, 2014 at 4:31 PM, Neil McKee <neil.mckee at inmon.com> wrote:

> Here is a link to a followup patch that exports the new sFlow structures.
>
>
> https://github.com/sflow/ovs/commit/e5a10227af2f9fc0a27bd52b40b616b22f3617ec
>
> (There is another "empty" commit showing up in between that represents
> the "git pull --rebase upstream master; git push" that I ran earlier
> today to bring in the interim changes from upstream.)
>
> I could have added the LACP stats retrieval to the "port_get_stats"
> method that was already defined in ofproto-provider.h but since there
> was already an "ofproto_port_is_lacp_current" method it seemed better
> to add another method "port_get_lacp_stats",  and then provide the
> implementation of it in ofproto-dpif.c.  I don't know how big a deal
> it is to add another method at this level?   If that can only happen
> on a major release, then perhaps we can do it a different way?  For
> example, if ofproto-dpif.c were to expose his implementation function
> then ofproto-dpif-sflow could call it directly.
>
> The sFlow module can only ask about the ports it has been formally
> given,  so I don't see any race/control-flow issues this time provided
> the struct ofport_dpif's pointer to "bundle" and it's pointer to
> "lacp" are not going to be moving around underfoot.
>
> Regards,
> Neil
>
> ------
> Neil McKee
> InMon Corp.
> http://www.inmon.com
>
>
> On Wed, Jul 9, 2014 at 3:08 PM, Neil McKee <neil.mckee at inmon.com> wrote:
> >
> > OK,  I'll reply again when I have extended this forked-repo to export
> the standard sFlow-LAG structure.
> >
> > Neil
> >
> > ------
> > Neil McKee
> > InMon Corp.
> > http://www.inmon.com
> >
> >
> > On Mon, Jul 7, 2014 at 8:55 AM, Ben Pfaff <blp at nicira.com> wrote:
> >>
> >> I took a look at the patch.  It's not necessary to submit a
> >> pull-request.
> >>
> >> The change seems reasonable to me.  Will you submit a followup patch to
> >> make use of the new statistics?  I do not think it makes sense to apply
> >> this until they are used.
> >>
> >> On Fri, Jun 27, 2014 at 11:34:11AM -0700, Neil McKee wrote:
> >> > OK,  I forked openvwitch/ovs on github to create this repo:
> >> >
> >> > https://github.com/sflow/ovs
> >> >
> >> > and then pushed the patch in there (with "Signed-off-by" in the commit
> >> > comment).
> >> >
> >> >
> https://github.com/sflow/ovs/commit/7aff910325fa3a4a11d363f09e06f83c64209485
> >> >
> >> > Should I submit a pull-request?
> >> >
> >> > Regards,
> >> > Neil
> >> >
> >> >
> >> > ------
> >> > Neil McKee
> >> > InMon Corp.
> >> > http://www.inmon.com
> >> >
> >> >
> >> > On Mon, Jun 23, 2014 at 1:20 PM, Ben Pfaff <blp at nicira.com> wrote:
> >> >
> >> > > On Fri, Jun 13, 2014 at 12:01:50PM -0700, Neil McKee wrote:
> >> > > >  Standard LACP counters are added to the LACP module, and
> >> > > >  the sFlow library and test modules are extended to support the
> >> > > >  export of those LACP counters as well as tunnel and OpenFlow
> >> > > >  related structures. None of these structures are actually
> >> > > >  exported yet,  so this patch should have no discernible
> >> > > >  effect. Hence no changes to the unit tests.
> >> > > >
> >> > > > Signed-off-by: Neil McKee <neil.mckee at inmon.com>
> >> > >
> >> > > Hi Neil.  This patch is badly whitespace damaged.  Could you repost
> >> > > it?  (If you can't make that work, then it's also acceptable to push
> >> > > it to a publicly accessible Git repo and point to it.)
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Ben.
> >> > >
> >
> >
>