Hi Greg,
I tried 4.4 and 4.16 both with ip_gre module loaded and didn't trigger this
error.
I will try more, thanks!
Yifeng
On Fri, Jun 22, 2018 at 5:17 PM, Gregory Rose wrote:
>
>
> On 6/22/2018 4:40 PM, Yifeng Sun wrote:
>
> Hi Greg,
>
> I am debugging a GRE related issue. Do you mind
On 6/22/2018 3:18 PM, Neal Shrader via dev wrote:
During the investigation of a kernel panic, we encountered a condition
that triggered a kernel panic due to a large skb with an unusual
geometry. Inside of the STT codepath, an effort is made to linearize
such packets to avoid trouble during
On 6/22/2018 4:40 PM, Yifeng Sun wrote:
Hi Greg,
I am debugging a GRE related issue. Do you mind telling me which
kernel version will lead to (err == -EEXIST) here?
else if (err == -EEXIST)
pr_warn("Cannot take GRE protocol entry - The ERSPAN
feature may not be
Hi Greg,
I am debugging a GRE related issue. Do you mind telling me which kernel
version will lead to (err == -EEXIST) here?
else if (err == -EEXIST)
pr_warn("Cannot take GRE protocol entry - The ERSPAN
feature may not be supported\n");
Thanks,
Yifeng
On Tue, Jun 5, 2018 at
On Thu, Jun 21, 2018 at 03:44:58PM -0700, Qiuyu Xiao wrote:
...
> Discussion
> ---
> The current proposal only allows CMS to choose either encrypting all
> tunnel traffic or not. A more flexible design allows CMS to define
> that only the tunnel traffic from certain logical networks
During the investigation of a kernel panic, we encountered a condition
that triggered a kernel panic due to a large skb with an unusual
geometry. Inside of the STT codepath, an effort is made to linearize
such packets to avoid trouble during both fragment reassembly and
segmentation in the linux
On 18/06/2018 14:16, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> From: Mark Kavanagh
>>
[snip]
>>
>> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
>> index 1e27a02..cbe4650 100644
>> --- a/vswitchd/vswitch.xml
>> +++ b/vswitchd/vswitch.xml
>> @@
On 18/06/2018 14:15, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> From: Mark Kavanagh
>>
>> Currently, packets are only copied to a single segment in the function
>> dpdk_do_tx_copy(). This could be an issue in the case of jumbo frames,
>> particularly when
On 18/06/2018 14:10, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> From: Michael Qiu
>>
>> When doing packet clone, if packet source is from DPDK driver,
>> multi-segment must be considered, and copy the segment's data one by
>> one.
>>
>> Also, lots of DPDK
On 18/06/2018 14:06, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> When enabled with DPDK OvS relies on mbufs allocated by mempools to
>> receive and output data on DPDK ports. Until now, each OvS dp_packet
>> has
>> had only one mbuf associated, which is
On 18/06/2018 12:55, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> In its current implementation dp_packet_shift() is also unaware of
>> multi-seg mbufs (that holds data in memory non-contiguously) and
>> assumes
>> that data exists contiguously in memory,
On 18/06/2018 12:52, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> The dp_packet_put_uninit() function is, in its current implementation,
>> operating on the data buffer of a dp_packet as if it were contiguous,
>> which in the case of multi-segment mbufs means they
On 18/06/2018 12:50, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> Most helper functions in dp-packet assume that the data held by a
>> dp_packet is contiguous, and perform operations such as pointer
>> arithmetic under that assumption. However, with the
On 18/06/2018 12:39, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> When a dp_packet is from a DPDK source, and it contains multi-segment
>> mbufs, the data_len is not equal to the packet size, pkt_len. Instead,
>> the data_len of each mbuf in the chain should be
On 18/06/2018 12:28, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> A new mutex, 'nonpmd_mp_mutex', has been introduced to serialise
>> allocation and free operations by non-pmd threads on a given mempool.
>>
>
> Can you explain why we need the mutex here? Can't
On 18/06/2018 12:23, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
>> From: Mark Kavanagh
>>
>> dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
>> possible the the resultant mbuf portion of the dp_packet contains
>> random data. For some mbuf
On 18/06/2018 12:20, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
[snip]
>>
>> @@ -626,13 +622,31 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
>>netdev_name, n_mbufs, socket_id,
>>dev->requested_n_rxq,
Hi Eelco,
On 18/06/2018 12:18, Eelco Chaudron wrote:
>
>
> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>
[snip]
>> Performance notes
>> =
>> In order to test for regressions in performance, tests were run on top
>> of master 88125d6 and v8 of this patchset, both with the
It's not a problem but it looks odd in output.
Signed-off-by: Ben Pfaff
---
tests/ovn.at | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/ovn.at b/tests/ovn.at
index 6553d17c6713..008ce02a49d2 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -2402,8 +2402,8
This commit renames HAVE_PYTHON to HAVE_PYTHON2 and PYTHON to PYTHON2
and adds HAVE_PYTHON and PYTHON with a different semantics:
- If PYTHON environment variable is set, use it as PYTHON
- If a python2 interpreter is available, PYTHON became the python2 interpreter
- If a python3 interpreter is
Python 2 will be End Of Life in 2020
(https://www.python.org/dev/peps/pep-0373/) and so some distributions
(for example Fedora) are trying to deprecated it.
This series of commit permits to build OVS with only Python 3 installed.
NOTE:
Currently most of the utilities and bugtool doesn't support
Nothing read or wrote this member, and "struct ldatapath" wasn't defined
anywhere.
Signed-off-by: Ben Pfaff
---
ovn/controller/ovn-controller.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/ovn/controller/ovn-controller.h b/ovn/controller/ovn-controller.h
index 3b15620ae42a..b13b3713c34d
This patch primarily replaces existing ndis RWlock based implementaion
for NAT in conntrack with a spinlock based implementation inside NAT,
module along with some conntrack optimization.
- The 'ovsNatTable' and 'ovsUnNatTable' tables are shared
between cleanup threads and packet processing
Conntrack 5-tuple consists of src address, dst address, src port,
dst port and protocol which will be unique to a ct session.
Use this information along with zone to compute hash.
Also re-factor conntrack code related to parsing netlink attributes.
Testing:
Verified loading/unloading the driver
This patch mainly changes a ndis RW lock for conntrack entry to a
spinlock along with some minor refactor in conntrack. Using
spinlock instead of RW lock as RW locks causes performance hits
when acquired/released multiple times.
- Use NdisInterlockedXX wrapper api's instead of InterlockedXX.
-
This patch series is primarily to refactor conntrack code for
better throughput with conntrack.
With this patch series TCP throughput with conntrack increased
by ~50%.
Anand Kumar (3):
datapath-windows: Use spinlock instead of RW lock for ct entry
datapath-windows: Implement locking in
Hi Alin,
Thanks for reviewing the patch series.
I will send out a v5 to address this issue and retain the acks.
Thanks,
Anand Kumar
On 6/22/18, 7:18 AM, "Alin Serdean" wrote:
> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org boun...@openvswitch.org> În numele Anand
> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org boun...@openvswitch.org> În numele Anand Kumar
> Trimis: Tuesday, June 19, 2018 8:33 PM
> Către: d...@openvswitch.org
> Subiect: [ovs-dev] [PATCH v4 3/3] datapath-windows: Compute ct hash
> based on 5-tuple and zone
>
>
> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org boun...@openvswitch.org> În numele Anand Kumar
> Trimis: Tuesday, June 19, 2018 8:33 PM
> Către: d...@openvswitch.org
> Subiect: [ovs-dev] [PATCH v4 2/3] datapath-windows: Implement locking in
> conntrack NAT.
>
> This patch
> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org boun...@openvswitch.org> În numele Anand Kumar
> Trimis: Tuesday, June 19, 2018 8:33 PM
> Către: d...@openvswitch.org
> Subiect: [ovs-dev] [PATCH v4 1/3] datapath-windows: Use spinlock instead
of
> RW lock for ct entry
>
> This
Dear Friend
My name is Attorney Kono Peter , I really do not mean to waste your time.
Considering the fact that this is a $1,600,000.00 Dollars deal shear rate 60/40
% and it's bank to bank wire transaction within Five working days.
Thanks
Brr.Kono Peter
I have replicated some of tests scenarios described below and confirm the
performance improvements.
I hope to get some time to review the code itself in the next week.
Regards,
Billy.
> -Original Message-
> From: Wang, Yipeng1
> Sent: Tuesday, May 15, 2018 5:13 PM
> To:
Shahaf,
No, I haven't looked into that issue, mainly because it seemed NIC-PMD related,
rather than OVS.
I can try to make a simple comparison with a loopback test in OVS using a
Napatech NIC and with/without HW acceleration.
Will get back to you on my findings.
Finn
From: Shahaf Shuler
Finn,
It is great that we are aligned w/ the finding.
I agree w/ your approach to take the relevant fields on the tcp_parse and limit
the offload rules to hw based on validated action.
There was one more issue from flavio about the single core performance w/ HWOL.
He saw performance drop when
34 matches
Mail list logo
