Thanks Romain. I’m actually talking about an array of *pointers* to
classifiers. That comes out to 2040 bytes.
===
Shashank Shanbhag
===
On Jun 19, 2015, at 5:32 PM, Romain Lenglet wrote:
>
> On June 18, 2015 at 2:39:31 PM, Shashank Shanbhag
On Fri, Jun 19, 2015 at 08:08:03PM +, Alin Serdean wrote:
> Add
> utilities/ovs-sim
> utilities/ovs-sim.1
>
> Found by issuing make.
>
> Signed-off-by: Alin Gabriel Serdean
Applied, thanks!
___
dev mailing list
dev@openvswitch.org
http://openvswit
When the extension is initialized the global reference count, used for
preventing early deallocation of the switch extension, is set to 1.
Enabling and then disabling the extension leaves the latter reference
count to zero. Because of this the switch context fails to be acquired,
i.e OvsAcquireSwit
This adds documentation for DPDK netdev to do an IVSHMEM shared memory to host
app or VM app
test using current OVS code. This example allows people to do learn how it is
done, so that they can
develop their own shared IVSHMEM memory applications. Also adds knowledge to
better system
setup for
Just a personal preference maybe we could drop OvsIpHlprCbVxlan all togheter.
Rest looks fine with me.
Acked-by: Alin Gabriel Serdean
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Friday, June 19, 2015 7:00 AM
Către: dev@openvswitch.org
S
I would rather leave them the way they are until we fix the actual problem
(disable from userspace, treat the dpif_probe_feature correctly)
Thanks,
Alin.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Friday, June 19, 2015 7:02 AM
Către: de
> On Jun 19, 2015, at 8:47 AM, Alin Serdean
> wrote:
>
> Just a personal preference maybe we could drop OvsIpHlprCbVxlan all togheter.
>
> Rest looks fine with me.
>
> Acked-by: Alin Gabriel Serdean
I don’t have any issues removing OvsIpHlprCbVxlan() since it is unused, and can
be resurrect
Cool!
Waiting for v3.
Alin.
-Mesaj original-
De la: Nithin Raju [mailto:nit...@vmware.com]
Trimis: Friday, June 19, 2015 7:01 PM
Către: Alin Serdean
Cc: dev@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH v2] datapath-windows: use correct dst port during
Vxlan Tx
> On Jun 19, 2015, at 8
> -volatile LONG gOvsSwitchContextRefCount = 1;
> +volatile LONG gOvsSwitchContextRefCount = 0;
This assignment does not matter anymore. So, I’d prefer not to initialize.
> static NDIS_STATUS OvsCreateSwitch(NDIS_HANDLE ndisFilterHandle,
>POVS_SWITCH_
A previous commit used the wrong DST port in the UDP header during Vxlan
Tx which caused Vxlan tunneling to break. Fixing it here..
Also included is a cosmetic fix in OvsDetectTunnelRxPkt() where we were
using htons() instead of ntohs(). Doesn't make a difference in practice
though.
One more chan
> On Jun 19, 2015, at 8:59 AM, Alin Serdean
> wrote:
>
> I would rather leave them the way they are until we fix the actual problem
> (disable from userspace, treat the dpif_probe_feature correctly)
Sure, let’s wait for reviews for the dpif_probe_feature() change. Personally, I
feel we shoul
When the extension is initialized the global reference count, used for
preventing early deallocation of the switch extension, is set to 1.
Enabling and then disabling the extension leaves the latter reference
count to zero. Because of this the switch context fails to be acquired,
i.e OvsAcquireSwit
hi Alin,
Do you know what is required to complete the implementation of
dpif_probe_feature() in the Windows datapath? Is it the flow validation logic?
thanks,
-- Nithin
> On Jun 18, 2015, at 6:47 PM, Alin Serdean
> wrote:
>
> This patch disables features which are not currently supported
> i
> On Jun 19, 2015, at 9:33 AM, Sorin Vinturis
> wrote:
>
> When the extension is initialized the global reference count, used for
> preventing early deallocation of the switch extension, is set to 1.
> Enabling and then disabling the extension leaves the latter reference
> count to zero. Because
To do it the proper way yes.
I really hate to do it this way but given the timeframe for 2.4 we could nuke
it later on.
Alin.
-Mesaj original-
De la: Nithin Raju [mailto:nit...@vmware.com]
Trimis: Friday, June 19, 2015 7:36 PM
Către: Alin Serdean
Cc: dev@openvswitch.org
Subiect: Re: [o
+1
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Nithin Raju
Trimis: Friday, June 19, 2015 7:13 PM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH v3] datapath-windows: use correct dst port during
Vxlan Tx
A previous commit used the wrong DST port in the
Now that we've branched for 2.4, we've decided to merge the OVN work into
master. While OVN is still under heavy development, the current code does
provide basic L2 overlay networking and scales to hundreds of simulated
hypervisors. By October, we hope to have security groups and L3 networks
On 18/06/2015 23:57, "Traynor, Kevin" wrote:
>
>
>> -Original Message-
>
>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Daniele Di
>
>> Proietto
>
>> Sent: Tuesday, June 16, 2015 7:39 PM
>
>> To: dev@openvswitch.org
>
>> Subject: [ovs-dev] [PATCH] dpif-netdev: Check for
Hi Nithin,
Thanks for the patch!
I managed to hit the assert again.
Child-SP RetAddr Call Site
d001`7b8db7f0 f801`4446530b nt!RtlAssert+0xeb
d001`7b8dbd50 f801`444620df OVSExt!OvsRemoveAndDeleteVport+0x25b
[c:\temp_june\19_06_2015\ovs\datapath-windows\ovsext\v
Reedited:
Steps to reproduce:
Install extension
*Enable extension on vSwitch
*Run vswitchd
Add internal/external port
*Stop the vswitchd
*Remove the vSwitch.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Alin Serdean
Trimis: Friday, June 19, 2015 9:55 PM
Cătr
> On Jun 19, 2015, at 11:55 AM, Alin Serdean
> wrote:
>
> Hi Nithin,
>
> Thanks for the patch!
>
> I managed to hit the assert again.
>
> Child-SP RetAddr Call Site
> d001`7b8db7f0 f801`4446530b nt!RtlAssert+0xeb
> d001`7b8dbd50 f801`444620df OVSExt!OvsRemov
No worries. Take your time :).
Alin.
-Mesaj original-
De la: Nithin Raju [mailto:nit...@vmware.com]
Trimis: Friday, June 19, 2015 10:01 PM
Către: Alin Serdean
Cc: dev@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH 1/2 v2] datapath-windows: Code refactoring and
fixes in Vport.c
> On Jun
On Fri, Jun 19, 2015 at 9:13 AM, Nithin Raju wrote:
> A previous commit used the wrong DST port in the UDP header during Vxlan
> Tx which caused Vxlan tunneling to break. Fixing it here..
>
> Also included is a cosmetic fix in OvsDetectTunnelRxPkt() where we were
> using htons() instead of ntohs()
On Fri, Jun 19, 2015 at 9:33 AM, Sorin Vinturis
wrote:
> When the extension is initialized the global reference count, used for
> preventing early deallocation of the switch extension, is set to 1.
> Enabling and then disabling the extension leaves the latter reference
> count to zero. Because of
Add
utilities/ovs-sim
utilities/ovs-sim.1
Found by issuing make.
Signed-off-by: Alin Gabriel Serdean
---
utilities/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/utilities/.gitignore b/utilities/.gitignore
index dda889b..1d59e28 100644
--- a/utilities/.gitignore
+++ b/utilitie
On Sun, Jun 7, 2015 at 11:09 AM, Ben Pfaff wrote:
> On Mon, Jun 01, 2015 at 03:34:51PM -0700, Andy Zhou wrote:
>> Replace the original PERF_FUNCTION_BEGIN and PERF_FUNCTION_END pair
>> with a single PERF macro. This design is also more flexible, removing
>> the restriction of have only one measure
This is the non-RFC version of the patch that I sent earlier this
week. At this point, I think it is still most important to discuss
the interface if there are ways to improve it. However, I've addressed the
outstanding issues that I mentioned previously and also rebased against
master, so I though
Until now, all fields that OVS can match against have been fixed
size (variable length headers can be skipped during parsing but
the match is fixed). However, Geneve options can vary in size
so we must not require the size of these fields to be known
at compile time.
This allows data types to be a
Currently we treat the entire NXM/OXM header, including length,
as an ID to define a field. However, this does not allow for
multiple lengths of a particular field.
If a field has been marked as variable, we should ignore the length
when looking up the field and only use the class and field. We
co
When reading in hex strings that form NXM fields, we don't need to
enforce size constraints if the fields are variable length.
Instead, we can set the header size based on the string length.
Signed-off-by: Jesse Gross
---
lib/nx-match.c | 20 ++--
1 file changed, 18 insertions(+)
Currently when an NXM field is encoded, the caller must specify
the length of the data being provided. However, this data is
always placed into a field of standard length. In order to
support variable length options, the length field must also
alter the size in the header. The previous implementati
It is technically correct to send the entire maximum length of
a field when it is variable length. However, it is awkward to
do so and not what one would naively expect. Since receivers will
internally zero-extend fields, we can do the opposite and trim
off leading zeros. This results in encodings
Tunnel metadata can be substantially larger than our existing fields
(up to 124 bytes in a single Geneve option) so this extends the size
of the data that we can handle with metaflow fields. This also
breaks a few tests that assume that their max size is also the
maximum that can be handled in a fi
The addition of Geneve metadata requires a large amount of additional
space to handle the maximum set of options. In most cases, this is
not a big deal since it is only temporary storage on the stack or
can be automatically stripped out for miniflows. However, userspace
tunnels need to deal with th
In order to work with Geneve options, we need to maintain a mapping
table between an option (defined by ) and
an NXM field that can be operated on for the purposes of matches,
actions, etc. This mapping must be explicitly specified by the
user.
Conceptually, this table could be communicated using
The current support for Geneve in OVS is exactly equivalent to VXLAN:
it is possible to set and match on the VNI but not on any options
contained in the header. This patch enables the use of options.
The goal for Geneve support is not to add support for any particular option
but to allow end users
This adds support for receiving variable length fields encoded in
NXM/OXM and mapping them into OVS internal structures. In order
for this to make sense, we need to define some semantics:
There are three lengths that matter in this process: the maximum
size of the field (represented as the existin
Sometimes we need to look at flow fields to understand how to parse
an attribute. However, masks don't have this information - just the
mask on the field. We already use the translated flow structure for
this purpose but this isn't always enough since sometimes we actually
need the raw netlink info
On June 18, 2015 at 2:39:31 PM, Shashank Shanbhag
(shashank.shanb...@gmail.com(mailto:shashank.shanb...@gmail.com)) wrote:
> Hi Ben,
>
> Please review when you get a chance. We would really like this to be in the
> 2.4 release. :-)
>
> This patch has the following changes suggested by you
39 matches
Mail list logo
