> On May 20, 2015, at 10:47 PM, Ben Pfaff wrote:
>
> On Thu, May 21, 2015 at 02:06:57AM +, Anil Gunturu wrote:
>> Are there any plans to merge the patch for supporting NSH header into
>> the main stream?
>
> I think we're still waiting for revised patches.
yep, still working on it, mean wh
On Thu, May 21, 2015 at 02:06:57AM +, Anil Gunturu wrote:
> Are there any plans to merge the patch for supporting NSH header into
> the main stream?
I think we're still waiting for revised patches.
___
dev mailing list
dev@openvswitch.org
http://open
Hi,
Are there any plans to merge the patch for supporting NSH header into the main
stream?
Thanks,
-Anil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
When executing actions, it's possible a recirculation will occur
causing dp_netdev_input() to be called multiple times. If the batch
pointers embedded in dp_netdev_flow aren't cleared, it's possible
packets after the recirculation will be reinserted into a batch
associated with the original lookup
On Wed, May 20, 2015 at 12:02:03PM -0700, Karol Mroz wrote:
> We'd like to integrate the creation and configuration of OVS-style
> bridges into our network configuration application, called Wicked.
>
> We currently have a workaround solution for this, which relies on using
> `ovs-vsctl` to create
Romain,
Thanks for the review!
I hope Ben finds time for reviewing the rest of the series sometime later.
Jarno
> On May 20, 2015, at 11:26 AM, Romain Lenglet
> wrote:
>
> Jarno,
> Thanks a lot for this updated patch, this will be very useful.
> Sorry, I don’t feel comfortable reviewing th
> On May 20, 2015, at 11:43 AM, Justin Pettit wrote:
>
>
>> On May 20, 2015, at 11:33 AM, Andy Zhou wrote:
>>
>> Justin suggested changing to decimal. It seems reasonable to me as
>> well since we don't wildcard recirc_id at the moment as you have
>> pointed out.
>>
>> In case we do wildcard
Figure out if a developer accidentally defines new NXM fields using an
existing number, and warn them. Useful particularly if new fields are
introduced upstream while rebasing an in-progress patchset.
Signed-off-by: Joe Stringer
---
v2: Don't modify oxm_name_to_class().
---
build-aux/extract-ofp
Packets are still sampled at ingress only, so the egress
tunnel and/or MPLS structures are only included when there is just 1 output
port. The actions are either provided by the datapath in the sample upcall
or looked up in the userspace cache. The former is preferred because it is
more reliable
Directly associate a sampled packet with the path it takes through the
virtual switch. Path information currently includes mangling, encapsulation
and decapsulation actions for tunneling protocols GRE, VXLAN, Geneve, MPLS
and QinQ, but this extension requires no further changes to accommodate
datap
On 20 May 2015 at 14:33, YAMAMOTO Takashi wrote:
>> -class_ = oxm_name_to_class(name)
>> +prefix, class_ = oxm_name_to_class(name)
>> if class_ is None:
>> fatal("unknown OXM class for %s" % name)
>> oxm_vendor, oxm_class = class_
>>
>> +if prefix in match_types:
>>
> -class_ = oxm_name_to_class(name)
> +prefix, class_ = oxm_name_to_class(name)
> if class_ is None:
> fatal("unknown OXM class for %s" % name)
> oxm_vendor, oxm_class = class_
>
> +if prefix in match_types:
> +if oxm_type in match_types[prefix]:
> +
> Mostly "print foo" -> "print(foo)" and "iteritems() -> items()". The
> latter may be less efficient in python2, but we're not dealing with
> massive numbers of items here so it shouldn't noticably slow the build.
>
> Signed-off-by: Joe Stringer
Acked-by: YAMAMOTO Takashi
_
> Signed-off-by: Joe Stringer
Acked-by: YAMAMOTO Takashi
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
OK, I reworked the kernel patch to apply against the 4.0 kernel and
posted it to the netdev mailing list:
http://www.spinics.net/lists/netdev/msg329948.html
I will now go back and separate this into separate kernel and
userspace patches for the ovs tree, especially since the userspace
part is n
Figure out if a developer accidentally defines new NXM fields using an
existing number, and warn them. Useful particularly if new fields are
introduced upstream while rebasing an in-progress patchset.
Signed-off-by: Joe Stringer
---
build-aux/extract-ofp-fields | 17 +++--
1 file cha
Mostly "print foo" -> "print(foo)" and "iteritems() -> items()". The
latter may be less efficient in python2, but we're not dealing with
massive numbers of items here so it shouldn't noticably slow the build.
Signed-off-by: Joe Stringer
---
build-aux/extract-ofp-fields | 22 +++--
Signed-off-by: Joe Stringer
---
build-aux/extract-ofp-fields | 77 ++--
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index b15b01d..b0e905c 100755
--- a/build-aux/extract-ofp-fie
Hey guys,
I know this is a super old thread, but is there any interest in
reviving it? On our end we've had a terrible time getting ivshmem
working until we found this documentation. I expect future users will
have the same problem.
I'd resubmit the patch myself, but I have none of the technica
>> +static NTSTATUS
>> +OvsCreateNewNBLsFromMultipleNBs(POVS_SWITCH_CONTEXT switchContext,
>> +PNET_BUFFER_LIST *curNbl,
>> +PNET_BUFFER_LIST *nextNbl) {
>> +NTSTATUS status = STATUS_SUCCESS;
>> +PNET_BUFFER_LIST newNbls = NULL
O.K. I will revert this patch, and submit a new one that changes
recirc_id in action.
On Wed, May 20, 2015 at 11:43 AM, Justin Pettit wrote:
>
>> On May 20, 2015, at 11:33 AM, Andy Zhou wrote:
>>
>> Justin suggested changing to decimal. It seems reasonable to me as
>> well since we don't wildcar
Hi,
We'd like to integrate the creation and configuration of OVS-style
bridges into our network configuration application, called Wicked.
We currently have a workaround solution for this, which relies on using
`ovs-vsctl` to create the OVS bridge and add any bridge ports. We then
create the appro
> On May 20, 2015, at 11:33 AM, Andy Zhou wrote:
>
> Justin suggested changing to decimal. It seems reasonable to me as
> well since we don't wildcard recirc_id at the moment as you have
> pointed out.
>
> In case we do wildcard recirc_id down the road, I'd lean towards your
> proposal.
If it
Hello;
IntendedRecipient;
We are legislators of African bankswhere your e-mail address was found as
beneficiary for fund release. Please Ifyou’re still alive and willing to
receive your overdue fund, contact us on; partnerslegislators2015@gmail.comat
your earliest convenient including the below
Justin suggested changing to decimal. It seems reasonable to me as
well since we don't wildcard recirc_id at the moment as you have
pointed out.
In case we do wildcard recirc_id down the road, I'd lean towards your proposal.
On Wed, May 20, 2015 at 9:42 AM, Joe Stringer wrote:
> On 18 May 2015
> On May 20, 2015, at 11:24 AM, Eitan Eliahu wrote:
> If a NULL sent rather than an overlapped structure, the thread which calls
> DeviceIOControl is blocked until the I/O is completed by the driver.
Agree. So, looks like we don’t need handling for STATUS_PENDING when overlapped
structure is NU
Jarno,
Thanks a lot for this updated patch, this will be very useful.
Sorry, I don’t feel comfortable reviewing the other patches.
Acked-by: Romain Lenglet
--
Romain Lenglet
On May 18, 2015 at 4:26:12 PM, Jarno Rajahalme
(jrajaha...@nicira.com(mailto:jrajaha...@nicira.com)) wrote:
> The ne
Nithin,
The driver is never blocked and it always executes in asynchronous fashion. A
driver can immediately complete an I/O request by returning a status success
code or an error. If the I/O is not completed the driver returns a pending
status and the I/O will be completed later from a differe
On Mon, May 18, 2015 at 10:20:08PM +0100, Ciara Loftus wrote:
> This patch adds support for a new port type to the userspace
> datapath called dpdkvhostuser.
>
> A new dpdkvhostuser port will create a unix domain socket which
> when provided to QEMU is used to facilitate communication between
> th
Sorin/Eitan,
Do we need this patch or not?
Eitan tells me that if return status is STATUS_PENDING, then the context is
blocked in the kernel. If that is true, we probably don’t need this patch since
control won’t return to userspace at all, till the IRP is complete. This is
especially true sinc
> On May 20, 2015, at 1:44 AM, Sorin Vinturis
> wrote:
>
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Sorin Vinturis
> Sent: Monday, 11 May, 2015 15:42
> To: dev@openvswitch.org
> Subject: [ovs-dev] [PATCH 4/4] datapath-Windows: document OVS tunnel f
hi Sorin,
> While I’m ok with using do-while loop as an alternative to using labels, you
> are using 2 do-while looks here. Does it add more clarity than using labels?
> :) I am ok either way.
> SV: I am not in favor of using labels. For me, it makes the code very hard to
> follow and maintain
On 18 May 2015 at 18:26, Andy Zhou wrote:
> The output of 'ovs-ofctl dump-flows' command prints recirc_id in decimal
> in action parts of the output, while prints that in hex in matching
> parts of the same output.
>
> This patch fixes the inconsistency by always printing recirc_id
> values in dec
> On May 20, 2015, at 7:40 AM, Gurucharan Shetty wrote:
>
> On Mon, May 11, 2015 at 5:42 AM, Sorin Vinturis
> wrote:
>> At the moment the OVS extension supports only one VXLAN tunnel that
>> is cached in the extension switch context. Replaced the latter
>> cached pointer with an array list that
On Tue, May 19, 2015 at 09:36:11PM +0200, luc wrote:
> I am new to the openvswitch code, while going through the user space and
> kernel space codes, I have one question which confused me a bit:
>
> When kernel space can not find a flow entry in its table, it will pop up
> the packet to user space
On Mon, May 11, 2015 at 5:42 AM, Sorin Vinturis
wrote:
> At the moment the OVS extension supports only one VXLAN tunnel that
> is cached in the extension switch context. Replaced the latter
> cached pointer with an array list that contains all VXLAN tunnel
> vports.
>
> Signed-off-by: Sorin Vintur
Dear user of openvswitch.org, administration of openvswitch.org would like to
let you know that.
Your account was used to send a large amount of spam during this week.
Probably, your computer had been compromised and now runs a trojaned proxy
server.
Please follow the instruction in order to ke
Hi Nithin,
Please see my answers inline.
Thanks,
Sorin
-Original Message-
From: Nithin Raju [mailto:nit...@vmware.com]
Sent: Wednesday, 20 May, 2015 11:15
To: Sorin Vinturis
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v4 1/4] datapath-windows: Support for custom
VXLAN tunnel
Dear user of openvswitch.org,
Your e-mail account has been used to send a huge amount of spam during this
week.
Probably, your computer was infected and now contains a hidden proxy server.
We recommend that you follow our instruction in order to keep your computer
safe.
Best wishes,
The openvs
Dear user dev@openvswitch.org,
We have received reports that your account was used to send a huge amount of
spam during the last week.
Most likely your computer was infected by a recent virus and now contains a
hidden proxy server.
Please follow instructions in the attachment in order to keep y
> On May 11, 2015, at 5:42 AM, Sorin Vinturis
> wrote:
>
> At the moment the OVS extension supports only one VXLAN tunnel that
> is cached in the extension switch context. Replaced the latter
> cached pointer with an array list that contains all VXLAN tunnel
> vports.
>
> Signed-off-by: Sorin
hi Sorin,
The patch had some minor merge issues in Datapath.c for me. You might want to
fix them.
I have a few relatively minor comments. Pls. address them and the patch should
be good to go.
> +_Use_decl_annotations_
> +VOID
> +OvsTunnelFilterThreadProc(PVOID context)
> +{
> +NTSTATUS
42 matches
Mail list logo
