On Sat, Sep 29, 2012 at 12:17 AM, Giuseppe Lettieri
wrote:
>
> Il giorno 29/set/2012, alle ore 01:44, Jesse Gross ha
> scritto:
>
>> Does this actually require changing the main loop? If it really is
>> the poll related changes that you mention it seems like they could be
>> contained to the ne
On Sat, Sep 29, 2012 at 7:05 AM, Luigi Rizzo wrote:
> jumping in the conversation: last year when Gaetano and I worked on
> this code, the main loop had multiple performance issues, including
> a) rebuilding from scratch the list of file descriptors on each iteration,
> b) ignoring the response fr
jumping in the conversation: last year when Gaetano and I worked on
this code, the main loop had multiple performance issues, including
a) rebuilding from scratch the list of file descriptors on each iteration,
b) ignoring the response from select() and firing all handlers (and perhaps
looking a
Il giorno 29/set/2012, alle ore 01:44, Jesse Gross ha
scritto:
> Does this actually require changing the main loop? If it really is
> the poll related changes that you mention it seems like they could be
> contained to the netdevs and userspace datapath. You could handle a
> batch of packets
On Fri, Sep 28, 2012 at 3:17 PM, Giuseppe Lettieri
wrote:
> To me, it was that the existing code mostly worked and had already proved to
> be a real performance improvement. This coupled with the limited manpower we
> could pour on the project. I understand that turning a single-threaded
> prog
To me, it was that the existing code mostly worked and had already proved to be
a real performance improvement. This coupled with the limited manpower we could
pour on the project. I understand that turning a single-threaded program into a
multi-threaded one looks scary, and with reason. On the
On Fri, Sep 28, 2012 at 3:49 AM, Giuseppe Lettieri
wrote:
> Hi all,
>
> we have finally found the time to finish work on this patch. We have
> addressed all the issues that were mentioned in the previous mails, plus
> some more that showed up later. We now pass all unit tests on both Linux and
> F
On Fri, Sep 28, 2012 at 09:23:01AM -0700, Ben Pfaff wrote:
> I think that there are now synchronization issues in vlog. The
> vlog_write_file() implementation assumes a single-threaded model
> (worker_request() isn't thread-safe). We could introduce per-thread
> state so that only the main thread
On Fri, Sep 28, 2012 at 12:49:16PM +0200, Giuseppe Lettieri wrote:
> we have finally found the time to finish work on this patch. We have
> addressed all the issues that were mentioned in the previous mails,
> plus some more that showed up later. We now pass all unit tests on
> both Linux and FreeB
Hi all,
we have finally found the time to finish work on this patch. We have
addressed all the issues that were mentioned in the previous mails, plus
some more that showed up later. We now pass all unit tests on both Linux
and FreeBSD and we can more confidently offer the patch to your
attent
On Fri, Aug 24, 2012 at 10:25:02AM +0200, Giuseppe Lettieri wrote:
> Il 20/08/2012 20:48, Ed Maste ha scritto:
> >>3. The datapath thread waits in poll() with each port's file descriptor in
> >>>the fd array. However there's currently no fd to signal a bridge
> >>>reconfiguration, so the poll() ha
Il 20/08/2012 20:48, Ed Maste ha scritto:
3. The datapath thread waits in poll() with each port's file descriptor in
>the fd array. However there's currently no fd to signal a bridge
>reconfiguration, so the poll() has to timeout before the thread will pick up
>the new config on the next time th
On Mon, Aug 20, 2012 at 02:48:01PM -0400, Ed Maste wrote:
> I've updated the snapshot of the threaded userspace datapath path with
> improvements Giuseppe and I have done over the last couple of weeks.
> The current patch is available here:
>
> http://people.freebsd.org/~emaste/openvswitch/threade
I've updated the snapshot of the threaded userspace datapath path with
improvements Giuseppe and I have done over the last couple of weeks.
The current patch is available here:
http://people.freebsd.org/~emaste/openvswitch/threaded-20120820.diff
This patch contains a number of minor improvements
On Wed, Aug 15, 2012 at 01:16:58PM -0400, Ed Maste wrote:
> >>> There may be some confusion about numbering. OpenFlow says that the
> >>> port number of the "local port" is 65534 (OFPP_LOCAL). The datapaths,
> >>> on the other hand, use port number 0 for the "local port". There is
> >>> supposed
>>> There may be some confusion about numbering. OpenFlow says that the
>>> port number of the "local port" is 65534 (OFPP_LOCAL). The datapaths,
>>> on the other hand, use port number 0 for the "local port". There is
>>> supposed to be translation going on at the interface between the
>>> datap
On 14 August 2012 21:21, Ed Maste wrote:
>> There may be some confusion about numbering. OpenFlow says that the
>> port number of the "local port" is 65534 (OFPP_LOCAL). The datapaths,
>> on the other hand, use port number 0 for the "local port". There is
>> supposed to be translation going on
> There may be some confusion about numbering. OpenFlow says that the
> port number of the "local port" is 65534 (OFPP_LOCAL). The datapaths,
> on the other hand, use port number 0 for the "local port". There is
> supposed to be translation going on at the interface between the
> datapath and th
On Tue, Aug 14, 2012 at 05:33:00PM +0200, Giuseppe Lettieri wrote:
> Il giorno 10/ago/2012, alle ore 19:20, Ben Pfaff ha scritto:
>
> > ...
> >> The datapath thread goes to 100% CPU in my tests, but this is
> >> expected, since everything is being done in software and no real I/O
> >> is being pe
Il giorno 10/ago/2012, alle ore 19:20, Ben Pfaff ha scritto:
> ...
>> The datapath thread goes to 100% CPU in my tests, but this is
>> expected, since everything is being done in software and no real I/O
>> is being performed. The main thread goes to ~65%, and this is less
>> expected (at least,
On Fri, Aug 10, 2012 at 01:38:33PM -0400, Ed Maste wrote:
> > We've had good improvements in a similar issue in dpif-linux by
> > switching to use "epoll". Can kqueue under FreeBSD do something
> > similar?
>
> Yes, epoll and kqueue basically provide the same functionality. What
> do you think a
> We've had good improvements in a similar issue in dpif-linux by
> switching to use "epoll". Can kqueue under FreeBSD do something
> similar?
Yes, epoll and kqueue basically provide the same functionality. What
do you think about incorporating something like libevent to abstract
that?
-Ed
On Fri, Aug 10, 2012 at 07:50:40PM +0200, Luigi Rizzo wrote:
> On Fri, Aug 10, 2012 at 10:17:04AM -0700, Ben Pfaff wrote:
> > On Fri, Aug 10, 2012 at 07:17:13PM +0200, Luigi Rizzo wrote:
> > > 1. rebuild the list of file descriptors from scratch at every iteration,
> > >looking at all possible
On Fri, Aug 10, 2012 at 06:36:46PM +0200, Giuseppe Lettieri wrote:
> > I'm very interested in seeing some up-to-date performance numbers
> > because introducing threads definitely raises the bar when it comes to
> > the need for careful programming, and that's only worthwhile if there
> > is a corr
Il giorno 09/ago/2012, alle ore 22:56, Ben Pfaff ha scritto:
> I'm very interested in seeing some up-to-date performance numbers
> because introducing threads definitely raises the bar when it comes to
> the need for careful programming, and that's only worthwhile if there
> is a correspondingly
On Thu, Aug 09, 2012 at 03:25:58PM -0400, Ed Maste wrote:
> On 9 August 2012 11:56, Ben Pfaff wrote:
>
> > I'm curious about the performance improvement. You mentioned a 10x
> > performance improvement. How much did CPU usage increase as part of
> > that? We already have users who complain whe
On 9 August 2012 11:56, Ben Pfaff wrote:
> I'm curious about the performance improvement. You mentioned a 10x
> performance improvement. How much did CPU usage increase as part of
> that? We already have users who complain when CPU usage spikes to 100%;
> I'm not sure that users will be happy
On Tue, Aug 07, 2012 at 11:36:56PM -0400, Ed Maste wrote:
> The original developer of the BSD port (Gaetano Catalli) also implemented a
> threaded version of the userspace datapath to increase performance. As
> with the original port, the threading work was done against Open vSwitch
> 1.1.0pre2.
The original developer of the BSD port (Gaetano Catalli) also implemented a
threaded version of the userspace datapath to increase performance. As
with the original port, the threading work was done against Open vSwitch
1.1.0pre2. Giuseppe Lettieri and I have ported it forward, and it's
functiona
29 matches
Mail list logo
