On Fri, Apr 20, 2012 at 01:11:39PM -0700, Jesse Gross wrote:
> On Thu, Apr 19, 2012 at 7:39 PM, Simon Horman wrote:
> > On Thu, Apr 19, 2012 at 03:53:35PM -0700, Jesse Gross wrote:
> >> On Wed, Apr 18, 2012 at 9:50 PM, Simon Horman wrote:
> >> > This is a not yet well exercised implementation of
On Sun, Apr 22, 2012 at 11:54:42AM -0400, Jamal Hadi Salim wrote:
> On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
>
> > STT isn't really doing TCP, it just lying and pretending to be
> > TCP to allow TSO to work! There is no packet ordering, sequence
> > numbers or any real transport
git shortlog -sn gives you an ordered list btw
On Apr 22, 2012, at 19:48, Ben Pfaff wrote:
> On Sun, Apr 22, 2012 at 06:44:56PM -0700, Ethan Jackson wrote:
>> Oh no, I plan to buy myself a glass of scotch and a slice of pie.
>> 1000 commits would be a cookie. I think we owe Ben two.
>
> Unle
On Sun, Apr 22, 2012 at 06:44:56PM -0700, Ethan Jackson wrote:
> Oh no, I plan to buy myself a glass of scotch and a slice of pie.
> 1000 commits would be a cookie. I think we owe Ben two.
Unless only commits in the openvswitch.org tree count, it's four:
blp@blp:~/nicira/ovs$ git log origin/
Oh no, I plan to buy myself a glass of scotch and a slice of pie.
1000 commits would be a cookie. I think we owe Ben two.
Ethan
On Sun, Apr 22, 2012 at 18:38, Justin Pettit wrote:
> Does that mean we have to buy you another cookie?
>
> --Justin
>
>
> On Apr 22, 2012, at 6:25 PM, Ethan Jackson
Does that mean we have to buy you another cookie?
--Justin
On Apr 22, 2012, at 6:25 PM, Ethan Jackson wrote:
> Assuming this makes it in, will be my 500th commit.
>
> Ethan
>
> On Sun, Apr 22, 2012 at 14:22, Ethan Jackson wrote:
>> The existing bridge_reconfigure() implementation is sub-opt
Assuming this makes it in, will be my 500th commit.
Ethan
On Sun, Apr 22, 2012 at 14:22, Ethan Jackson wrote:
> The existing bridge_reconfigure() implementation is sub-optimal.
> When adding lots of new ports, on every pass through the run loop
> it allocates a bunch of "struct iface"s and "stru
The existing bridge_reconfigure() implementation is sub-optimal.
When adding lots of new ports, on every pass through the run loop
it allocates a bunch of "struct iface"s and "struct port"s, only to
destroy them when out of time. Additionally, when there are errors
adding or deleting ports, it can
---
vswitchd/bridge.c |2 --
1 file changed, 2 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index f4a10e6..15f6cb7 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -66,7 +66,6 @@ struct iface {
struct hmap_node name_node; /* In struct bridge's "iface_by_name"
On Fri, Apr 20, 2012 at 08:36:57AM -0700, Ben Pfaff wrote:
> On Fri, Apr 20, 2012 at 09:24:05AM +0900, Simon Horman wrote:
> > This may be used in a similar way to nxm_mf_fields
> > to handle parsing and serialisation of OXM TLVs.
> >
> > Signed-off-by: Simon Horman
>
> My own thought for how to
On Sun, Apr 22, 2012 at 08:24:35AM -0700, Stephen Hemminger wrote:
>
>
> > This hook is based on a hook of the same name provided by UDP. It
> > provides
> > a way for to receive packets that have a TCP header and treat them in
> > some
> > alternate way.
> >
> > It is intended to be used by an
From: Jamal Hadi Salim
Date: Sun, 22 Apr 2012 11:54:42 -0400
> On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
>
>> Therefore Simon's
>> proposed hook is the only way to support it. But exposing that
>> hook does allow for other misuse.
>
> If you object to this, then you gotta obje
This is great, Ben. Just a few minor things:
> +Out-of-band control has the following benefits:
> +
> +- Simplicity: Out-of-band control slightly simplifies the switch
> + implementation.
> +
> +- Reliability: Excessive switch traffic volume cannot interfere
> + with control tra
On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
> STT isn't really doing TCP, it just lying and pretending to be
> TCP to allow TSO to work! There is no packet ordering, sequence
> numbers or any real transport layer.
True. It is a nice engineering hack but even as a protocol enhance
> This hook is based on a hook of the same name provided by UDP. It
> provides
> a way for to receive packets that have a TCP header and treat them in
> some
> alternate way.
>
> It is intended to be used by an implementation of the STT tunneling
> protocol within Open vSwtich's datapath. A pro
> From: Simon Horman
> Date: Thu, 19 Apr 2012 13:53:35 +0900
>
> > This hook is based on a hook of the same name provided by UDP. It
> > provides
> > a way for to receive packets that have a TCP header and treat them
> > in some
> > alternate way.
> >
> > It is intended to be used by an implem
16 matches
Mail list logo
