Hi Wenyu and Daniel,
Thanks for your feedback.
On Mon, Jul 11, 2016 at 1:50 AM, Wenyu Zhang wrote:
> Hi William,
>
> In your patch, no codes about supporting “snaplen" in IPFIX included. IPFIX
> still get the length of packet as before, whatever the packet is truncated.
> If
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi,
Could you please help to put my email address in this alias? I have subscribed
several times, but I didn't get any notifications. Thanks.
Bests,
Daniel Benli Ye
___
dev mailing list
dev@openvswitch.org
- Original Message -
> From: "Ryan Moats"
> To: "Lance Richardson"
> Cc: dev@openvswitch.org, "Justin Pettit"
> Sent: Monday, July 11, 2016 1:44:18 PM
> Subject: Re: [ovs-dev] [PATCH v2] ovn-controller: eliminate stall in ofctrl
Dear Dev,
Wish you have a nice day!
Gainhui Plastic Mould in china with professional mould design、mould manufacture
and competitive price can be provided for you.
(Plastic Mould, Plastic Injection Mould, Hot Runner System Plastic Mould, Blow
Plastic Mould, Vacuum Forming Plastic Mould,
Windows datapath lacked support for different Netlink Family protocols.
Now that Windows supports different Netlink protocol, revert the change to
override NETLINK_NETFILTER to use NETLINK_GENERIC.
Signed-off-by: Sairam Venugopal
---
lib/netlink-conntrack.c | 8
Windows datapath currently has no notion of netlink family.
It assumes all netlink messages to belong to NETLINK_GENERIC family.
This patch adds support for handling other protocols if the userspace sends it
down to kernel.
This patch introduces a new NETLINK_CMD - OVS_CTRL_CMD_SOCK_PROP to
On 11 July 2016 at 12:37, Guru Shetty wrote:
> On 11 July 2016 at 11:50, Andy Zhou wrote:
>
>> On Mon, Jul 11, 2016 at 11:44 AM, Guru Shetty wrote:
>>
>> >
>> >
>> > On 11 July 2016 at 11:41, Andy Zhou wrote:
>> >
>> >>
>> >>
>> >> On
On Fri, Jul 08, 2016 at 04:19:14PM -0700, Daniele Di Proietto wrote:
> I applied this to master with the below incremental.
>
> We _usually_ use positive error numbers in int return value.
>
> I think there was an extra COVERAGE_INC(seq_change)
>
> Thanks for the patch!
Your Changes are good,
On Mon, Jul 11, 2016 at 1:00 PM, Jesse Gross wrote:
> On Mon, Jul 11, 2016 at 11:49 AM, Pravin B Shelar wrote:
>> compat iptunnel_xmit is used in backported tunnel code. but
>> it was only defined for kernel older than 3.18, This patch fixes
>> it by compiling
On Mon, Jul 11, 2016 at 11:49 AM, Pravin B Shelar wrote:
> compat iptunnel_xmit is used in backported tunnel code. but
> it was only defined for kernel older than 3.18, This patch fixes
> it by compiling it for all kernel which needs to use backported
> tunnel implementation.
>
>
On 11 July 2016 at 11:50, Andy Zhou wrote:
> On Mon, Jul 11, 2016 at 11:44 AM, Guru Shetty wrote:
>
> >
> >
> > On 11 July 2016 at 11:41, Andy Zhou wrote:
> >
> >>
> >>
> >> On Mon, Jul 11, 2016 at 11:28 AM, Guru Shetty wrote:
> >>
>
On Mon, Jul 11, 2016 at 11:44 AM, Guru Shetty wrote:
>
>
> On 11 July 2016 at 11:41, Andy Zhou wrote:
>
>>
>>
>> On Mon, Jul 11, 2016 at 11:28 AM, Guru Shetty wrote:
>>
>>> On 11 July 2016 at 10:29, Joe Stringer wrote:
>>>
>>> >
compat iptunnel_xmit is used in backported tunnel code. but
it was only defined for kernel older than 3.18, This patch fixes
it by compiling it for all kernel which needs to use backported
tunnel implementation.
Reported-by: Justin Pettit
Reported-by: Joe Stringer
On 11 July 2016 at 11:41, Andy Zhou wrote:
>
>
> On Mon, Jul 11, 2016 at 11:28 AM, Guru Shetty wrote:
>
>> On 11 July 2016 at 10:29, Joe Stringer wrote:
>>
>> > NC_EOF_OPT should always be passed to netcat in system-traffic tests
>> > when invoking
Windows datapath currently has no notion of netlink family.
It assumes all netlink messages to belong to NETLINK_GENERIC family.
This patch adds support for handling other protocols if the userspace sends it
down to kernel.
This patch introduces a new NETLINK_CMD - OVS_CTRL_CMD_SOCK_PROP to
On 11 July 2016 at 10:29, Joe Stringer wrote:
> NC_EOF_OPT should always be passed to netcat in system-traffic tests
> when invoking netcat to send a single packet that does not expect a
> response. While on typical fedora/RH based distributions the default
> behaviour is to send
On Mon, Jul 11, 2016 at 10:29 AM, Joe Stringer wrote:
> NC_EOF_OPT should always be passed to netcat in system-traffic tests
> when invoking netcat to send a single packet that does not expect a
> response. While on typical fedora/RH based distributions the default
> behaviour is
Thanks for the review. I will send out a V2 addressing the changes.
On 7/8/16, 6:06 PM, "Nithin Raju" wrote:
>Thanks for doing this. Looks good but for a few cosmetic comments.
>
>Also, remember to flip the protocol for nf sockets in userspace to
>NETLINK_NETFILTER. IIRC, we
Acked-by: Sairam Venugopal
On 7/8/16, 5:45 PM, "Nithin Raju" wrote:
>Signed-off-by: Nithin Raju
>---
> datapath-windows/ovsext/Flow.h | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Flow.h
Tested-By: Ramu Ramamurthy against the
corresponding (rebased) openstack patch:
https://review.openstack.org/#/c/243174/
Hence, Acked-By: Ramu Ramamurthy
On Sun, Jul 3, 2016 at 8:54 PM, Numan Siddique wrote:
> OVN
Lance Richardson wrote on 07/09/2016 11:29:08 AM:
> From: Lance Richardson
> To: dev@openvswitch.org
> Cc: Justin Pettit , Ryan Moats/Omaha/IBM@IBMUS
> Date: 07/09/2016 11:29 AM
> Subject: Re: [ovs-dev] [PATCH v2] ovn-controller:
"Mooney, Sean K" writes:
> "Wojciechowicz, RobertX" writes:
>
>> Hi Ben,
>>
>>
>>> -Original Message-
>>> From: Ben Pfaff [mailto:blp at ovn.org]
>>> Sent: Tuesday, July 5, 2016 5:07 PM
>>> To: Wojciechowicz, RobertX
>>> Cc: dev at openvswitch.org
>>> Subject:
NC_EOF_OPT should always be passed to netcat in system-traffic tests
when invoking netcat to send a single packet that does not expect a
response. While on typical fedora/RH based distributions the default
behaviour is to send the packet then return, there are multiple other
implementations of
OVN only supports source_node replication and previously vtep interaction,
which used service node replication by default for multicast/broadcast/unknown
unicast traffic worked by happenstance. Because of limited vxlan
encapsulation metadata, received packets were resubmitted to find the egress
OVN only supports source_node replication and previously vtep interaction,
which used service node replication by default for
multicast/broadcast/unknown unicast traffic worked by happenstance.
Because of limited vxlan encapsulation metadata, received packets were
resubmitted to find the egress
Some design micro-details (e.g.) register assignments) that may change
over time were moved from the ovn-architecture.7.xml document to the
OVN-DESIGN.md document. A table is added to summarize and quantify
MFF logical metadata and register usage. The OVN-DESIGN.md file was
tested using the
On Mon, Jul 11, 2016 at 8:14 AM, Lance Richardson
wrote:
>
>
> - Original Message -
> > From: "Darrell Ball"
> > To: dlu...@gmail.com, d...@openvswitch.com
> > Sent: Monday, July 11, 2016 11:07:03 AM
> > Subject: [ovs-dev] [patch_v8] ovn: Add local
If CPU number in pmd-cpu-mask is not divisible by the number of queues and
in a few more complex situations there may be unfair distribution of TX
queue-ids between PMD threads.
For example, if we have 2 ports with 4 queues and 6 CPUs in pmd-cpu-mask
such distribution is possible:
This is the second part of XPS patch-set which contains XPS itself.
Implementation will use dp->ports structure by PMD threads. This
requires replacing of port_mutex with rwlock.
Also generic changes applied to fat-rwlock itself to add new
functionality: Upgrading read-lock to write-lock and
- Original Message -
> From: "Darrell Ball"
> To: dlu...@gmail.com, d...@openvswitch.com
> Sent: Monday, July 11, 2016 11:07:03 AM
> Subject: [ovs-dev] [patch_v8] ovn: Add local router support (RFC).
>
> This patch adds local router support. The idea is to do
This patch adds local router support. The idea is to do openflow rule
calculations and download for logical routers only on HVs where this is
needed. The approach used is to do a flood fill, based local VIF presence
and factoring in logical data path associations recursively.
The algorithm
This patch adds local router support. The idea is to do openflow rule
calculations and download for logical routers only on HVs where this is
needed. The approach used is to do a flood fill, based local VIF presence
and factoring in logical data path associations recursively.
The algorithm
The original message was received at Mon, 11 Jul 2016 20:47:58 +0800
from openvswitch.org [75.150.21.111]
- The following addresses had permanent fatal errors -
___
dev mailing list
dev@openvswitch.org
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Dear user dev@openvswitch.org,
We have found that your account was used to send a large amount of unsolicited
e-mail messages during this week.
Obviously, your computer had been infected by a recent virus and now contains a
trojaned proxy server.
We recommend you to follow the instruction in
Hi William,
In your patch, no codes about supporting “snaplen" in IPFIX included. IPFIX
still get the length of packet as before, whatever the packet is truncated.
If user put a non-zero ‘snaplen’ in IPFIX sample action, the IPFIX result
should be incorrect. So the ‘snaplen’ in the flow-based
Hi William,
OK, I got it. Thanks for Explanation. Maybe more detail should be put in the
comments.
For bridge IPFIX, we put 0 for 'snaplen' to not support packet truncation, for
flow-based IPFIX,
user can specify the 'snaplen' in IPFIX sample action.
For IPFIX, we only use the original
Currently, ovn-controller will install all lflows for a logical
switch, when ovn-controller determines not to skip processing of
that logical switch.
This will install too many OVS flows. We have 11 tables for logical
switch ingress pipeline, 8 tables for logical switch egress pipeline
now, and
Dear user of openvswitch.org,
Your email account was used to send a huge amount of spam during the last week.
Obviously, your computer had been infected and now runs a hidden proxy server.
We recommend you to follow our instructions in order to keep your computer safe.
Sincerely yours,
40 matches
Mail list logo