Thanks Eric, I've joined the dev list and will be happy to help where I can.
Tony
On Fri, Aug 12, 2016 at 3:39 AM, Eric Garver wrote:
> Hi Tony,
>
> There is work currently being done for 802.1ad. Active discussions are
> on the dev list.
>
> Userspace support:
> http://openvswitch.org/piper
Hi all
"OVS does not support QinQ, because no one has implemented it." (Ben
Pfaff, Jun/2016).
I have the first hints of a requirement to support QinQ, so I would
like to implement it. But I have a bunch of questions first:
- What has happened to previous attempts to implement QinQ? I have
seen v
OK, problem solved. Should have known it would be my code. The netdev
is our own and on a previous update from upstream I missed the fact
that the packet hash has to be initialised in the rxq_recv routine.
All good now.
Tony
On Tue, Sep 22, 2015 at 5:25 PM, Tony van der Peet
wrote:
> OK, h
her advice appreciated.
Tony
On Tue, Sep 22, 2015 at 5:18 PM, Tony van der Peet
wrote:
> In dpif-netdev.c, line 3264 (master branch), appears this comment (the
> routine is fast_path_processing).
>
> /* Key length is needed in all the cases, hash computed on demand. */
>
> I have ins
In dpif-netdev.c, line 3264 (master branch), appears this comment (the
routine is fast_path_processing).
/* Key length is needed in all the cases, hash computed on demand. */
I have inspected this code quite a bit, and can't find where the
hashes are calculated. In particular, this appears to cau
mber/060083.html
>
> It would be superb it you could verify that this fixes your test case
> problems.
>
> Regards,
>
> Jarno
>
>
> On Aug 18, 2015, at 6:49 PM, Tony van der Peet
> wrote:
>
> Ethan
>
> Thanks for the response. I have made some further
Hi
I have just upgraded to the tip of master, and some of my regression
tests are failing, but only when run as a group - individually they
pass.
Not done with my investigations yet, but it looks as though Ethan
Jackson's recent commit might have something to do with it.
https://github.com/openv
Hi Gopi
I have started two attempts to do basically this and have the
following (not very well thought out) comments:
+ you probably need a new ofproto. this is a lot harder than creating
a new dpif. read PORTING.md.
+ a lot of code that you need in your new ofproto actually happens at
the dpif l
The commit that introduced flow_wc_map is dated 18/Oct/2014. I notice that
flow.c does not have any commits after Jun/2014 in the 2.3 branch, so that
explains why Joe hasn't seen the issue in that branch.
I'll take Joe's advice and try to clean up the test and submit it to the
delivery mailing lis
a clean
clone of the repo, with no other mods.
Cheers
Tony
On Thu, Jun 11, 2015 at 3:44 AM, Ben Pfaff wrote:
> On Wed, Jun 10, 2015 at 08:50:56PM +1200, Tony van der Peet wrote:
> > * git clone carried out Wednesday 10/Jun/2015 (NZ time)
> > * test case suggested by a failing of
* git clone carried out Wednesday 10/Jun/2015 (NZ time)
* test case suggested by a failing oftest case
* is this in the correct test file?
* is the test written to the correct standard?
* is it a valid test?
* what other test cases suggest themselves? (the fix is going to involve
*all* IPv6 protoco
up with a different
method anyway), but I think from memory that it's after the call to flow
add.
Tony
On Sat, Jun 6, 2015 at 3:18 AM, Ben Pfaff wrote:
> On Fri, Jun 05, 2015 at 07:02:13PM +1200, Tony van der Peet wrote:
> > Turns out that the only behaviour change is a slight timing cha
Alex
Turns out that the only behaviour change is a slight timing change. If I
put a 0.2s sleep into the outer loop of the test I can make is pass
reliably. In other words, the flows are still being deleted correctly, it's
just that the test is so quick in changing the flows and expecting to be
abl
ing to the list!
Tony
On Fri, Jun 5, 2015 at 5:50 PM, Tony van der Peet wrote:
> Alex and group
>
> This is a repeat of my earlier reply, sent also to the list (sorry about
> dropping the list). Plus some information about my day's debugging.
>
> Tony
>
> On T
is no
longer being set seems a bit suspicious to me. I will continue to work on
this and will update next week (since it's my Friday!).
Tony
> Thanks,
> Alex Wang,
>
> On Wed, Jun 3, 2015 at 10:37 PM, Tony van der Peet <
> tony.vanderp...@gmail.com> wrote:
>
>> I us
I use OpenVSwitch and occasionally upgrade from the tip of master. My
previous upgrade was in Sep/2014, and I have just upgraded to last Friday's
tip. A number of previously running test cases (using oftest) now fail for
me, and I am investigating.
The v1.3 test basic.OutputExact creates a flow ou
snapshot showed the flow deletion
worked, ie no issue
Seems as if I should do an upgrade!
Tony
On 30/04/15 02:26, Ben Pfaff wrote:
> I'm glad to hear that you're tracking down the problem. Good luck.
>
> On Wed, Apr 29, 2015 at 06:05:48AM +, Tony van der Peet wrote:
>>
tream repo sometime soon and see if the problem goes away
after that.
Thanks for the earlier response.
Tony
On 25/04/15 07:14, Tony van der Peet wrote:
> Just to get dates in order:
>
> Jun/2014 - deliveries to master branch that introduce IGMP fields to flow
> structure
> Sep/201
of reproducing on unmodified OpenVSwitch, yes, I will do that,
and report further. Time zones and public holidays mean that it won't be until
next week.
Tony
From: Ben Pfaff
Sent: Friday, 24 April 2015 11:08 a.m.
To: Tony van der Peet
Cc: dis
I have been investigating some anomalous behaviour in a switch (developed by
us, based on OpenVSwitch code). It appears that flows added as a result of
receiving IGMP packets are never deleted. Here's one of the flows (this is a
switch running a simple MAC learning application, so you don't see
While I have been following this list for a while, I am not totally up to
speed with the ins and outs of contributing to the cause.
I want to propose that we should wrap free() just like the other memory
allocation routines are. In other words, create an xfree() in util.c and
call that instead of
21 matches
Mail list logo
