Re: [ovs-dev] [ovs-dev,PATCHv2] dpif-netlink: Add meter support.

Bleep bloop. Greetings Justin Pettit, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 356, Warnings:

Re: [ovs-dev] dpif-netlink: Add meter support.

Bleep bloop. Greetings Justin Pettit, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 356, Warnings:

[ovs-dev] [PATCHv2] dpif-netlink: Add meter support.

From: Andy Zhou To work with kernel datapath that supports meter. Signed-off-by: Andy Zhou Signed-off-by: Justin Pettit --- v1->v2: D'oh. Stupid typo. This is Andy's patch. I made a few fixes and cleanups, so I wouldn't mind another set of eyes. Also, this may have impact on the Windows

[ovs-dev] [PATCH] dpif-netlink: Add meter support.

From: Andy Zhou To work with kernel datapath that supports meter. Signed-off-by: Andy Zhou Signed-off-by: Justin Pettit --- This is Andy's patch. I made a few fixes and cleanups, so I wouldn't mind another set of eyes. Also, this may have impact on the Windows port, since I don't believe it

[ovs-dev] [PATCH V2 2/2] datapath: Add missing code in ip_tunnel_lookup()

The compat rpl_ip_tunnel_lookup() function was missing some code added in Linux kernel release 4.3 but not backported in the initial commit. This also allows us to remove an old hack in erspan_rcv() that was zeroing out the key parameter so that the tunnel lookups wouldn't fail. Fixes: 8e53509c

[ovs-dev] [PATCH V2 1/2] compat: Fix gre header bug

Commit 436d36db introduced a bug into the gre header build for gre and ip gre type tunnels. __vlan_hwaccel_push_inside does not check whether the vlan tag is even present. So check first and avoid padding space for a vlan tag that isn't present. Fixes: 436d36db ("compat: Fixups for newer

Re: [ovs-dev] [PATCH 2/2] datapath: Ignore key in ip_tunnel_lookup

On 6/28/2018 5:03 PM, William Tu wrote: On Thu, Jun 28, 2018 at 4:01 PM, Greg Rose wrote: The key value is always zero in ip_tunnel_lookup() for all OVS tunnels but in received packets it is set. Just ignore it for the ip_tunnel_lookup() in the same manner as erspan_rcv(). Fixes: 8e53509c

[ovs-dev] 答复: [bug] ovs crash when call xlate_normal_flood

Sorry.This is not ovs‘s bug. 发件人: Linhaifeng 发送时间: 2018年6月21日 13:54 收件人: 'd...@openvswitch.org' 主题: 答复: [bug] ovs crash when call xlate_normal_flood Or stop upcall thread before xlate_remove_ofproto in destruct. 发件人: Linhaifeng 发送时间: 2018年6月21日 13:49 收件人: 'd...@openvswitch.org'

Re: [ovs-dev] [PATCH 2/2] datapath: Ignore key in ip_tunnel_lookup

On Thu, Jun 28, 2018 at 4:01 PM, Greg Rose wrote: > The key value is always zero in ip_tunnel_lookup() for all OVS > tunnels but in received packets it is set. Just ignore it for > the ip_tunnel_lookup() in the same manner as erspan_rcv(). > > Fixes: 8e53509c ("gre: introduce native tunnel

Re: [ovs-dev] [PATCH 1/2] compat: Fix gre header bug

On Thu, Jun 28, 2018 at 4:00 PM, Greg Rose wrote: > Commit 436d36db introduced a bug into the gre header build for gre and > ip gre type tunnels. __vlan_hwaccel_push_inside does not check whether > the vlan tag is even present. So check first and avoid padding space > for a vlan tag that isn't

[ovs-dev] [PATCH 1/2] compat: Fix gre header bug

Commit 436d36db introduced a bug into the gre header build for gre and ip gre type tunnels. __vlan_hwaccel_push_inside does not check whether the vlan tag is even present. So check first and avoid padding space for a vlan tag that isn't present. Fixes: 436d36db ("compat: Fixups for newer

[ovs-dev] [PATCH 2/2] datapath: Ignore key in ip_tunnel_lookup

The key value is always zero in ip_tunnel_lookup() for all OVS tunnels but in received packets it is set. Just ignore it for the ip_tunnel_lookup() in the same manner as erspan_rcv(). Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN") Signed-off-by: Greg Rose ---

Re: [ovs-dev] [ovs-dev, v3, 2 of 4] conntrack: Fix fragmentation checks.

Bleep bloop. Greetings Darrell Ball, 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. git-am: fatal: corrupt patch at line 307 Repository lacks necessary blobs to fall back on 3-way merge.

[ovs-dev] [patch v3 4/4] conntrack: Support global invalid packet stats.

Signed-off-by: Darrell Ball --- NEWS| 2 + lib/conntrack.c | 114 +--- lib/conntrack.h | 13 ++ lib/ct-dpif.c | 24 +++ lib/ct-dpif.h | 13 ++ lib/dpctl.c | 62

[ovs-dev] [patch v3 2/4] conntrack: Fix fragmentation checks.

The ipv4 fragmentation check is broken and allows fragments through. There were fragile and poorly maintainable checks in extract_l3_ipv* designed to save a few cycles. The checks make assumptions about what sanity checks may have been done and could be skipped based on inferring from the value

[ovs-dev] [patch v3 3/4] tests: Add more fragmentation tests.

Tests are added to cover out of order fragments, overlapping fragments and multiple extension headers in the case of IPv6. Signed-off-by: Darrell Ball --- tests/system-kmod-macros.at | 16 tests/system-traffic.at | 200 +++

[ovs-dev] [patch v3 1/4] packets: Handle line continuations for packets.

Line continuations are useful for specifying big packets in hex form in tests. Allow the hex packet to include '\'s to specify continuations. Also line length is limited to 998 in patches because of SMTP limits. Creating patches with longer lines lines leads to corrupted patches. Signed-off-by:

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

> > > > After a bit of chewing on the finer grained filtering question, I take back > the above suggestion regarding "lb_force_snat_ip", as it will not work > in all cases. Implementing finer grained filtering would involve checking > several pieces of information; I am not sure it is worth the

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On 06/28/2018 02:26 PM, Darrell Ball wrote: On Thu, Jun 28, 2018 at 9:41 AM, Mark Michelson > wrote: Hi Darrell, I'm not 100% sure this is correct. I think this change would only be correct if the router's IP addresses are also load balancer VIPs. In

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On Thu, Jun 28, 2018 at 11:59 AM, Darrell Ball wrote: > > > On Thu, Jun 28, 2018 at 11:26 AM, Darrell Ball wrote: > >> On Thu, Jun 28, 2018 at 9:41 AM, Mark Michelson >> wrote: >> >>> Hi Darrell, >>> >>> I'm not 100% sure this is correct. I think this change would only be >>> correct if the

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Great. It works: sudo make check-system-userspace TESTSUITEFLAGS="-k ovn" Thanks again! On Thu, Jun 28, 2018 at 11:57 AM, Darrell Ball wrote: > > > On Thu, Jun 28, 2018 at 11:55 AM, Han Zhou wrote: > >> Thanks Darrell! These tests weren't even listed in make check >> TESTSUITEFLAGS="--list".

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On Thu, Jun 28, 2018 at 11:26 AM, Darrell Ball wrote: > On Thu, Jun 28, 2018 at 9:41 AM, Mark Michelson > wrote: > >> Hi Darrell, >> >> I'm not 100% sure this is correct. I think this change would only be >> correct if the router's IP addresses are also load balancer VIPs. In the >> case where

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On Thu, Jun 28, 2018 at 11:55 AM, Han Zhou wrote: > Thanks Darrell! These tests weren't even listed in make check > TESTSUITEFLAGS="--list". What's the best way to run them? I'd like to run > them for each of my patch to make sure there is no regression. > sudo make check-kmod -C _gcc

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Thanks Darrell! These tests weren't even listed in make check TESTSUITEFLAGS="--list". What's the best way to run them? I'd like to run them for each of my patch to make sure there is no regression. On Thu, Jun 28, 2018 at 11:46 AM, Darrell Ball wrote: > > > On Thu, Jun 28, 2018 at 11:44 AM,

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On Thu, Jun 28, 2018 at 11:44 AM, Han Zhou wrote: > Hi Mark, what I meant is the test for the feature of LB in Gateway. If we > had a test case, the problem would have been noticed when Lorenzo is > working on ICMP feature. > Here are tests: system-ovn 113: ovn -- 2 LRs connected via LS,

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On 28 June 2018 at 11:44, Han Zhou wrote: > Hi Mark, what I meant is the test for the feature of LB in Gateway. If we > had a test case, the problem would have been noticed when Lorenzo is > working on ICMP feature. > We have a few test cases. The tests weren't run likely as they are system

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Hi Mark, what I meant is the test for the feature of LB in Gateway. If we had a test case, the problem would have been noticed when Lorenzo is working on ICMP feature. On Thu, Jun 28, 2018 at 11:29 AM, Mark Michelson wrote: > Lorenzo actually brought up in today's OVN IRC meeting that writing

Re: [ovs-dev] [PATCH] gre: Fix GRE loading bug by separating ERSPAN from tunnel

Thanks for the review. I sent another patch. Best, Yifeng On Thu, Jun 28, 2018 at 8:03 AM, Gregory Rose wrote: > On 6/27/2018 12:02 PM, Yifeng Sun wrote: > >> On kernel versions (for example, 3.10) where upstream provides GRE >> functionality but no ERSPAN, GRE can fail to initialize. Because

[ovs-dev] [PATCHv2] gre: Fix GRE loading bug by separating ERSPAN from tunnel

On kernel versions (for example, 3.10) where upstream provides GRE functionality but no ERSPAN, GRE can fail to initialize. Because there is no ERSPAN feature in kernel, openvswitch kernel module will try to register its own IPPROTO_GRE, instead of using the upstream GRE functionality. But GRE

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Lorenzo actually brought up in today's OVN IRC meeting that writing ICMP tests for IPv6 is problematic right now. IPv4 tests have an M4 macro called OVN_POPULATE_ARP that they call. This manually populates tables in OVS so that there are no ARP requests being sent during the test. It does this

Re: [ovs-dev] [ovs-dev, v2, 1 of 3] conntrack: Fix fragmentation checks.

Thanks Some long lines in the test file are leading to subsequent corruption in the patch I fixed it and will resend Darrell On Wed, Jun 27, 2018 at 11:54 PM, 0-day Robot wrote: > Bleep bloop. Greetings Darrell Ball, I am a robot and I have tried out > your patch. > Thanks for your

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

On Thu, Jun 28, 2018 at 9:41 AM, Mark Michelson wrote: > Hi Darrell, > > I'm not 100% sure this is correct. I think this change would only be > correct if the router's IP addresses are also load balancer VIPs. In the > case where the VIPs do not overlap with the router IP addresses, I think >

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Agree with Mark that ICMP is still needed for non VIP on gateway. But LB feature on GW is also important. Shall we have a test case to cover this particular scenario? On Thu, Jun 28, 2018 at 9:41 AM, Mark Michelson wrote: > Hi Darrell, > > I'm not 100% sure this is correct. I think this change

Re: [ovs-dev] [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow

On Thu, Jun 28, 2018 at 11:22:49AM +, Shahaf Shuler wrote: > Hi Ian, Flavio, Hi! > Thursday, June 28, 2018 12:14 PM, Ian Stokes: > > Subject: Re: [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow > > > > On 6/25/2018 2:21 PM, Shahaf Shuler wrote: > > > Hi, > > > > > > Here is a joint work

Re: [ovs-dev] [ovs-dev, v3, 6 of 6] netdev-linux: monitor and offload LAG slaves to TC

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 132, Warnings:

Re: [ovs-dev] [ovs-dev, v3, 5 of 6] netdev-linux: assign LAG devs to tc blocks

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 103, Warnings:

Re: [ovs-dev] [ovs-dev, v3, 4 of 6] netdev-linux: indicate if netdev is a LAG master

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 73, Warnings: 0,

Re: [ovs-dev] [ovs-dev, v3, 3 of 6] rtnetlink: extend parser to include kind of master and slave

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 115, Warnings:

Re: [ovs-dev] [ovs-dev, v3, 2 of 6] netdev-provider: add class op to get block_id

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 221, Warnings:

Re: [ovs-dev] [ovs-dev, v3, 1 of 6] tc: allow offloading of block ids

Bleep bloop. Greetings John Hurley, 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: ERROR: Too many signoffs; are you missing Co-authored-by lines? Lines checked: 436, Warnings:

Re: [ovs-dev] [patch v2] ovn: Fix gateway load balancing.

Hi Darrell, I'm not 100% sure this is correct. I think this change would only be correct if the router's IP addresses are also load balancer VIPs. In the case where the VIPs do not overlap with the router IP addresses, I think we'd want to have the ICMP responses still in place. On

[ovs-dev] [PATCH v3 6/6] netdev-linux: monitor and offload LAG slaves to TC

A LAG slave cannot be added directly to an OvS bridge, nor can a OvS bridge port be added to a LAG dev. However, LAG masters can be added to OvS. Use TC blocks to indirectly offload slaves when their master is attached as a linux-netdev to an OvS bridge. In the kernel TC datapath, blocks link

[ovs-dev] [PATCH v3 5/6] netdev-linux: assign LAG devs to tc blocks

Assign block ids to LAG masters that are added to OvS as linux-netdevs and offloaded via offload API calls. Only LAG masters are assigned to blocks. To ensure uniqueness, the block ids are determined by the netdev ifindex. Implement a get_block_id op for linux netdevs to achieve this.

[ovs-dev] [PATCH v3 4/6] netdev-linux: indicate if netdev is a LAG master

If a linux netdev is added to OvS that is a LAG master (for example, a bond or team netdev) then record this in bool form in the dev struct. Use the link info extracted from rtnetlink calls to determine this. Signed-off-by: John Hurley Reviewed-by: Dirk van der Merwe Reviewed-by: Simon Horman

[ovs-dev] [PATCH v3 3/6] rtnetlink: extend parser to include kind of master and slave

Extend the rtnetlink_parse function to look for linkinfo attributes and, in turn, store pointers to the master and slave kinds (if any) in the rtnetlink_change struct. Signed-off-by: John Hurley Reviewed-by: Simon Horman Reviewed-by: Dirk van der Merwe Signed-off-by: Jakub Kicinski ---

[ovs-dev] [PATCH v3 2/6] netdev-provider: add class op to get block_id

Add a new class op for netdevs to get the block_id if one exists. The block_id is used in offload ops to group multiple qdiscs together. Stub calls are made to the new class op (implementation to follow in further patches). The default block_id of 0 (no block) will be used in these cases.

[ovs-dev] [PATCH v3 1/6] tc: allow offloading of block ids

Blocks, in tc classifiers, allow the grouping of multiple qdiscs with an associated block id. Whenever a filter is added to/removed from this block, the filter is added to/removed from all associated qdiscs. Extend TC offload functions to take a block id as a parameter. If the id is zero then the

[ovs-dev] [PATCH v3 0/6] offload Linux LAG devices to the TC datapath

This patchset extends OvS TC and the linux-netdev implementation to support the offloading of Linux Link Aggregation devices (LAG) and their slaves. TC blocks are used to provide this offload. Blocks, in TC, group together a series of qdiscs. If a filter is added to one of these qdiscs then it is

Re: [ovs-dev] [PATCH v8 01/13] netdev-dpdk: fix mbuf sizing

On 12/06/2018 07:51, santosh wrote: > Hi, > > > On Monday 11 June 2018 09:51 PM, Tiago Lam wrote: >> From: Mark Kavanagh >> >> There are numerous factors that must be considered when calculating >> the size of an mbuf: >> - the data portion of the mbuf must be sized in accordance With Rx >>

[ovs-dev] [PATCH v1 12/14] dpdk-tests: Add uni-tests for multi-seg mbufs.

In order to create a minimal environment that allows the tests to get mbufs from an existing mempool, the following approach is taken: - EAL is initialised (by using the main dpdk_init()) and a (very) small mempool is instantiated (mimicking the logic in dpdk_mp_create()). This mempool

[ovs-dev] [PATCH v1 13/14] dpdk-tests: Accept other configs in OVS_DPDK_START

As it stands, OVS_DPDK_START() won't allow other configs to be set before starting the ovs-vswitchd daemon. This is a problem since some configs, such as the "dpdk-multi-seg-mbufs=true" for enabling the multi-segment mbufs, need to be set prior to start OvS. To support other options,

[ovs-dev] [PATCH v1 14/14] dpdk-tests: End-to-end tests for multi-seg mbufs.

The following tests are added to the DPDK testsuite to add some coverage for the multi-segment mbufs: - Check that multi-segment mbufs are disabled by default; - Check that providing `other_config:dpdk-multi-seg-mbufs=true` indeed enables mbufs; - Using a DPDK port, send a random packet out and

[ovs-dev] [PATCH v1 11/14] netdev-dpdk: support multi-segment jumbo frames

From: Mark Kavanagh Currently, jumbo frame support for OvS-DPDK is implemented by increasing the size of mbufs within a mempool, such that each mbuf within the pool is large enough to contain an entire jumbo frame of a user-defined size. Typically, for each user-defined MTU, 'requested_mtu', a

[ovs-dev] [PATCH v1 10/14] netdev-dpdk: copy large packet to multi-seg. mbufs

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 multi-segment mbufs are involved. This patch calculates the number of segments needed by a packet and copies the

[ovs-dev] [PATCH v1 09/14] dp-packet: copy data from multi-seg. DPDK mbuf

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 mbuf's info is missed during a copy, like packet type, ol_flags, etc. That information is very important for DPDK to do

[ovs-dev] [PATCH v1 08/14] dp-packet: Handle multi-seg mbufs in resize__().

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 allocated with the maximum possible size, taking the MTU into account. This approach, however, doesn't allow us to

[ovs-dev] [PATCH v1 07/14] dp-packet: Handle multi-seg mubfs in shift() func.

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, memmove'ing data to perform the shift. To add support for multi-seg mbuds a new set of functions was introduced,

[ovs-dev] [PATCH v1 06/14] dp-packet: Handle multi-seg mbufs in helper funcs.

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 introduction of multi-segment mbufs, where data is non-contiguous, such assumptions are no longer possible. Some

[ovs-dev] [PATCH v1 03/14] dp-packet: Fix allocated size on DPDK init.

When enabled with DPDK OvS deals with two types of packets, the ones coming from the mempool and the ones locally created by OvS - which are copied to mempool mbufs before output. In the latter, the space is allocated from the system, while in the former the mbufs are allocated from a mempool,

[ovs-dev] [PATCH v1 04/14] netdev-dpdk: Serialise non-pmds mbufs' alloc/free.

A new mutex, 'nonpmd_mp_mutex', has been introduced to serialise allocation and free operations by non-pmd threads on a given mempool. free_dpdk_buf() has been modified to make use of the introduced mutex. Signed-off-by: Tiago Lam --- lib/netdev-dpdk.c | 30 +++--- 1

[ovs-dev] [PATCH v1 02/14] dp-packet: Init specific mbuf fields.

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 fields, specifically those related to multi-segment mbufs and/or offload features, random values may cause

[ovs-dev] [PATCH v1 01/14] netdev-dpdk: fix mbuf sizing

From: Mark Kavanagh There are numerous factors that must be considered when calculating the size of an mbuf: - the data portion of the mbuf must be sized in accordance With Rx buffer alignment (typically 1024B). So, for example, in order to successfully receive and capture a 1500B packet,

[ovs-dev] [PATCH v1 00/14] Support multi-segment mbufs

Overview This patchset introduces support for multi-segment mbufs to OvS-DPDK. Multi-segment mbufs are typically used when the size of an mbuf is insufficient to contain the entirety of a packet's data. Instead, the data is split across numerous mbufs, each carrying a portion, or

Re: [ovs-dev] [PATCH] gre: Fix GRE loading bug by separating ERSPAN from tunnel

On 6/27/2018 12:02 PM, Yifeng Sun wrote: On kernel versions (for example, 3.10) where upstream provides GRE functionality but no ERSPAN, GRE can fail to initialize. Because there is no ERSPAN feature in kernel, openvswitch kernel module will try to register its own IPPROTO_GRE, instead of using

Re: [ovs-dev] [PATCH v2] dpdk: Support both shared and per port mempools.

On 06/27/2018 02:58 PM, Ian Stokes wrote: > This commit re-introduces the concept of shared mempools as the default > memory model for DPDK devices. Per port mempools are still available but > must be enabled explicitly by a user. > > OVS previously used a shared mempool model for ports with the

Re: [ovs-dev] [iovisor-dev] [RFC PATCH 00/11] OVS eBPF datapath.

Hi Alexei, Thanks a lot for the feedback! On Wed, Jun 27, 2018 at 8:00 PM, Alexei Starovoitov wrote: > On Sat, Jun 23, 2018 at 05:16:32AM -0700, William Tu wrote: >> >> Discussion >> == >> We are still actively working on finishing the feature, currently >> the basic forwarding and

Re: [ovs-dev] [PATCH] mac-learning: Increase default mac table size to 8K from 2K

On 27 Jun 2018, at 17:11, Ben Pfaff wrote: On Wed, Jun 27, 2018 at 05:02:31PM +0200, Eelco Chaudron wrote: On 27 Jun 2018, at 16:09, Ben Pfaff wrote: On Wed, Jun 27, 2018 at 01:24:25PM +0200, Eelco Chaudron wrote: In field deployments of OVS (mostly in combination with OpenStack) we

Re: [ovs-dev] [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow

Hi Ian, Flavio, Thursday, June 28, 2018 12:14 PM, Ian Stokes: > Subject: Re: [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow > > On 6/25/2018 2:21 PM, Shahaf Shuler wrote: > > Hi, > > > > Here is a joint work from Mellanox and Napatech, to enable the flow hw > > offload with the DPDK generic

[ovs-dev] How many queues are supported at egress port in OVS for traffic shaping ? Please point to the file name

How to know the queue mechanism in OVS from source code , mean to say how to check the number of queues at egress port in OVS . Regards Rakesh Kumar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS-DPDK public meeting

Minutes of meeting Wed 27th June. Next meeting: 11th July. Attendees: Anders, Simon, Shahaf, Olga, Aaron, Sameh, Yipeng, Ian, Vishal, Johann, Tiago, Kevin. === GENERAL === - Meeting frequency -- Will move to bi-weekly as heading towards 2.10 -- Next meeting 11th July 16:00 UTC - 0 day

Re: [ovs-dev] [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow

On 6/25/2018 2:21 PM, Shahaf Shuler wrote: Hi, Here is a joint work from Mellanox and Napatech, to enable the flow hw offload with the DPDK generic flow interface (rte_flow). The basic idea is to associate the flow with a mark id (a unit32_t number). Later, we then get the flow directly from

[ovs-dev] [patch v2 2/3] tests: Add more fragmentation tests.

Tests are added to cover out of order fragments, overlapping fragments and multiple extension headers in the case of IPv6. Signed-off-by: Darrell Ball --- tests/system-kmod-macros.at | 16 tests/system-traffic.at | 200 +++

[ovs-dev] [patch v2 3/3] conntrack: Support global invalid packet stats.

Signed-off-by: Darrell Ball --- NEWS| 2 + lib/conntrack.c | 114 +--- lib/conntrack.h | 13 ++ lib/ct-dpif.c | 24 +++ lib/ct-dpif.h | 13 ++ lib/dpctl.c | 62

[ovs-dev] [patch v2 1/3] conntrack: Fix fragmentation checks.

The ipv4 fragmentation check is broken and allows fragments through. There were fragile and poorly maintainable checks in extract_l3_ipv* designed to save a few cycles. The checks make assumptions about what sanity checks may have been done and could be skipped based on inferring from the value