Bleep bloop. Greetings Martin Varghese, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 84 characters long (recommended limit is 79)
#246 FILE:
Encap & Decap actions are extended to support MPLS packet type.
The encap & decap adds and removes MPLS header at the start of
packet.
CLI syntax for Encap & Decap
- encap(mpls(ether_type=0x8847))
- decap(packet_type(ns=x,type=y))
Signed-off-by: Martin Varghese
---
The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS header
between ethernet header and the IP header. Though this behaviour is fine
for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it does
not suffice the L2 VPN requirements. In L2 VPN the ethernet packets must be
On Fri, Oct 4, 2019 at 1:09 AM William Tu wrote:
>
> Hi Tonghao,
>
> Thanks for the patch.
>
> > On 29 Sep 2019, at 19:09, xiangxia.m@gmail.com wrote:
> >
> > > From: Tonghao Zhang
> > >
> > > This series patch optimize openvswitch.
> > >
> > > Patch 1, 2, 4: Port Pravin B Shelar patches to
On Mon, Oct 07, 2019 at 10:10:34AM +0200, Damijan Skvarc wrote:
> memory leak is reported by valgrind while executing functional test
> "ovsdb-tool convert-to-standalone"
>
> ==13842== 2,850 (280 direct, 2,570 indirect) bytes in 7 blocks are definitely
> lost in loss record 20 of 20
> ==13842==
On Mon, Oct 07, 2019 at 10:30:07AM +0200, Damijan Skvarc wrote:
> problem is reported by valgrind while running functional tests:
>
> ==21043== 160 (88 direct, 72 indirect) bytes in 1 blocks are definitely lost
> in loss record 7 of 8
> ==21043==at 0x4C2DB8F: malloc (in
>
On Mon, Oct 07, 2019 at 12:34:55AM -0400, martinbj2...@gmail.com wrote:
> From: Martin Zhang
>
> Signed-off-by: Martin Zhang
Thanks. I applied this to master and backported it as far as
branch-2.5.
___
dev mailing list
d...@openvswitch.org
On 07.10.2019 18:11, Ilya Maximets wrote:
On 07.10.2019 18:07, William Tu wrote:
On Mon, Oct 7, 2019 at 5:06 AM Ilya Maximets wrote:
On 04.10.2019 23:21, William Tu wrote:
The libunwind unw_word_t type is defined as uint32_t for 32-bit
system and uint64_t for 64-bit system. The patch fixes
On 07.10.2019 18:07, William Tu wrote:
On Mon, Oct 7, 2019 at 5:06 AM Ilya Maximets wrote:
On 04.10.2019 23:21, William Tu wrote:
The libunwind unw_word_t type is defined as uint32_t for 32-bit
system and uint64_t for 64-bit system. The patch fixes the
compile error using PRIxPTR to print
On Mon, Oct 7, 2019 at 5:06 AM Ilya Maximets wrote:
>
> On 04.10.2019 23:21, William Tu wrote:
> > The libunwind unw_word_t type is defined as uint32_t for 32-bit
> > system and uint64_t for 64-bit system. The patch fixes the
> > compile error using PRIxPTR to print this value.
> >
> > Fixes:
On Wed, Oct 2, 2019 at 2:54 AM Han Zhou wrote:
>
>
> On Mon, Sep 30, 2019 at 6:51 AM wrote:
> >
> > From: Numan Siddique
> >
> > This partially revers the commit -
> 298701dbc99645700be41680a43d049cb061847a
> > as the commit [1] disables the conjunction.
> >
> > We still need the changes to
On 04.10.2019 23:21, William Tu wrote:
The libunwind unw_word_t type is defined as uint32_t for 32-bit
system and uint64_t for 64-bit system. The patch fixes the
compile error using PRIxPTR to print this value.
Fixes: e2ed6fbeb18c ("fatal-signal: Catch SIGSEGV and print backtrace.")
From: Martin Zhang
Signed-off-by: Martin Zhang
---
ofproto/ofproto-dpif-sflow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-sflow.c b/ofproto/ofproto-dpif-sflow.c
index 03bd763..9abaab6 100644
--- a/ofproto/ofproto-dpif-sflow.c
+++
problem is reported by valgrind while running functional tests:
==21043== 160 (88 direct, 72 indirect) bytes in 1 blocks are definitely lost in
loss record 7 of 8
==21043==at 0x4C2DB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21043==by 0x45EE2E: xmalloc
memory leak is reported by valgrind while executing functional test
"ovsdb-tool convert-to-standalone"
==13842== 2,850 (280 direct, 2,570 indirect) bytes in 7 blocks are definitely
lost in loss record 20 of 20
==13842==at 0x4C2DB8F: malloc (in
15 matches
Mail list logo
