Dear Google User,
This is to officially inform you that you have been selected as a winner for
using Google services, we wait
your urgent respond for our official notification letter for the claim of your
winning prize GBP 950,000.00
{Nine Hundred and Fifty Thousand Great British Pounds
Hi Justin:
Please back-port the above patches to branch-2.10 too as it fails there
too.
On Thu, Sep 5, 2019 at 4:24 PM Justin Pettit wrote:
>
> > On Sep 5, 2019, at 4:08 PM, Han Zhou wrote:
> >
> > Shall older branches support latest kernels? If so, some kernel patches
> need to be
> On Sep 5, 2019, at 4:08 PM, Han Zhou wrote:
>
> Shall older branches support latest kernels? If so, some kernel patches need
> to be backported to avoid compile failure. For example, on 2.11, below patch
> is required for kernel module compile to pass on Ubuntu with kernel version
>
On Tue, Sep 3, 2019 at 3:10 PM Justin Pettit wrote:
>
> Signed-off-by: Justin Pettit
> ---
> NEWS | 3 ++-
> debian/changelog | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index ff2647739375..f2d44e4630bb 100644
> --- a/NEWS
> +++ b/NEWS
>
On Wed, Sep 4, 2019 at 7:10 AM Ilya Maximets wrote:
>
> > Hi Eelco,
> >
> > Thanks for your testing and review.
> >
> > On Wed, Sep 4, 2019 at 1:04 AM Eelco Chaudron
> > wrote:
> >>
> >>
> >>
> >> On 27 Aug 2019, at 1:02, William Tu wrote:
> >>
> >> > The patch adds support for using
The patch adds support for using need_wakeup flag in AF_XDP rings.
A new option, use_need_wakeup, is added. When this option is used,
it means that OVS has to explicitly wake up the kernel RX, using poll()
syscall and wake up TX, using sendto() syscall. This feature improves
the performance by
All of these 2.5 to 2.8 release series look good to me.
Acked-by: Ben Pfaff
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hi Ben,
Please consider this as a gentle remainder and provide your inputs on the
below issue.
This issue has been discussed earlier in the following thread.
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-April/048494.html
Best Regards,
Anil Kumar.
-Original Message-
From: Anil
For userspace datapath, currently only the bridge itself, the LOCAL port,
can be the tunnel endpoint to encap/decap tunnel packets. This patch
enables non-bridge port as tunnel endpoint. One use case is for users to
create a bridge and a vtep port as tap, and configure underlay IP at vtep
port
> Did some more testing and with PVP I see a performance decrease, with
> physical to physical I see an increase.
> Tests are performed with a port redirect open flow rule on an ixgbe
> (Xeon E5-2690 v4 2.60GHz):
>
>
On Tue, Sep 03, 2019 at 06:07:26PM +0300, Ilya Maximets wrote:
> Useful for tracking where the uninitialized memory came from.
> Report example:
>
> Thread 13 revalidator11:
> Conditional jump or move depends on uninitialised value(s)
> at 0x4C35D96: __memcmp_sse4_1 (in
On 9/4/2019 10:37 PM, Justin Pettit wrote:
Thanks, Greg. I pushed the patches you sent for all the appropriate branches
(2.5-2.8). I sent out patches to do bug patch releases for all those branches,
too, that will include these. Hopefully we'll get those merged and all the
releases out
See inlines below, and will sent a v2 early next week.
On 5 Sep 2019, at 14:40, Ilya Maximets wrote:
Hi Eelco,
Thanks for the patch! Looks reasonable.
One comment is that it's better to explicitly initialize the
flag in common_construct. I see that we doesn't initialize
'started' flag, but
This is related to the section called "Adding a Gateway".
Added workaround command for a known issue in networking-ovn.
Even after the issue is resolved, it may be useful to have this
in the tutorial, so folks have a feel for how OVN keeps track
of chassis gateway.
Also, removed redundant route
The comment was incorrectly updated. Fix it to the
correct value of 32 pad bytes.
/* --- cacheline 5 boundary (320 bytes) --- */
union {
struct {
struct netdev_stats stats; /* 320 336 */
/* --- cacheline 5 boundary (320 bytes) was 16 bytes ago ---
Hi Eelco,
Thanks for the patch! Looks reasonable.
One comment is that it's better to explicitly initialize the
flag in common_construct. I see that we doesn't initialize
'started' flag, but this might be fixed too.
More comments inline.
Best regards, Ilya Maximets.
On 05.09.2019 14:48, Eelco
"txfh2007" writes:
> Hi Aaron:
>
> Sorry to bother, I have submit a patch via ovs-dev, but as I
> changed the signoff mail address and got the robot errors(see
> below). This new signoff mail address is my new working mail which is
> not in the author list(txfh2...@aliyun.com is in the
Currently, OVS does not register and therefore not handle the
interface reset event from the DPDK framework. This would cause a
problem in cases where a VF is used as an interface, and its
configuration changes.
As an example in the following scenario the MAC change is not
detected/acted upon
On Thu, Sep 5, 2019 at 3:19 AM Han Zhou wrote:
>
>
> On Mon, Sep 2, 2019 at 9:32 AM wrote:
> >
> > From: Numan Siddique
> >
> > Suppose there is a provider network (with localnet port) and it is
> > connected to a logical router via a distributed gateway router port.
> > When an external
Thanks James,
I can understand the root cause now.
Best Regards,
Wei Yanqin
From: James Page
Sent: Thursday, September 5, 2019 3:42 PM
To: Yanqin Wei (Arm Technology China)
Cc: Ilya Maximets ; ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] SIGILL ovs branch-2.12/arm64/DPDK
On Thu, Sep 5, 2019
Hi Ilya,
Thanks for the clarification. It looks application is strong couple with DPDK.
I will follow your discussion under this bug.
Best Regards,
Wei Yanqin
-Original Message-
From: Ilya Maximets
Sent: Thursday, September 5, 2019 3:41 PM
To: Yanqin Wei (Arm Technology China) ; James
Hi All
I’m encountered a very strange problem that ovs-vswitchd exited
silently without any exceptions while ovsdb-server running normally, I’m using
openvswitch 2.9.2
I didn’t find any valuable log except that
ovs|1|unixctl|WARN|failed to connect to
Not a code review. Just a few notes about patch formatting.
Best regards, Ilya Maximets.
On 25.07.2019 15:16, Anju Thomas wrote:
> Currently OVS maintains explicit packet drop/error counters only on
> port level. Packets that are dropped as part of normal OpenFlow
> processing are counted in
On Thu, Sep 5, 2019 at 8:34 AM Yanqin Wei (Arm Technology China) <
yanqin@arm.com> wrote:
> Is it possible a configuration issue for building OVS userspace program ,
> which should not enable crc for xgene cpu? DPDK library is linked with OVS
> program during OVS building. It should not
On 05.09.2019 10:34, Yanqin Wei (Arm Technology China) wrote:
> Is it possible a configuration issue for building OVS userspace program ,
> which should not enable crc for xgene cpu?
There is a arm64-xgene1-linux-gcc target that can be used for a legacy
make-based build system. New meson based
Thanks, I’ve CC’ed Ben so he can look at the comments regarding his
earlier comment :)
Looking forward for the next version…
//Eelco
On 4 Sep 2019, at 11:24, Anju Thomas wrote:
Hi Eelco,
Since I have not received any more comments, let me respond to your
comments:
-Original
Is it possible a configuration issue for building OVS userspace program , which
should not enable crc for xgene cpu? DPDK library is linked with OVS program
during OVS building. It should not import compiling configuration from DPDK,
right?
Best Regards,
Wei Yanqin
-Original Message-
Hi Ilya,
Thanks a lot for the explanation. As per your suggestion, I will move all the
counters (including 'tx_retries')to some structure and place a pointer to it
in netdev_dpdk structure so that the padding size will not vary with the
introduction of new counters in future.
@Kevin Traynor :
28 matches
Mail list logo
