[ovs-dev] Shipment

See Attached File For Shipment Details___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dpctl: Expand the flow dump type filter

On 25 July 2018 at 23:13, Justin Pettit wrote: > > > On Jul 25, 2018, at 9:17 AM, Simon Horman > wrote: > > > > On Thu, Jul 12, 2018 at 09:46:40AM +0300, Roi Dayan wrote: > >> > >> it could. > >> currently offload unit tests in the repo fail and needs an update > >> though they cannot be fixed b

Re: [ovs-dev] [PATCH 2/2] Revert "dpctl: Expand the flow dump type filter"

Hi, On 25 July 2018 at 23:17, Justin Pettit wrote: > > > On Jul 25, 2018, at 2:11 PM, Ben Pfaff wrote: > > > > On Wed, Jul 25, 2018 at 02:01:32PM -0700, Justin Pettit wrote: > >> Commit ab15e70eb587 ("dpctl: Expand the flow dump type filter") had a > >> number of issues with style, build breaka

Re: [ovs-dev] [PATCH] ofproto: Return error codes for Rule insertions

> Currently, rule_insert() API does not have return value. There are some possible > scenarios where rule insertions can fail at run-time even though the static > checks during rule_construct() had passed previously. > Some possible scenarios for failure of rule insertions: > **) Rule insertions ca

Re: [ovs-dev] [PATCH] ofproto: Return error codes for Rule insertions

> Currently, rule_insert() API does not have return value. There are some possible > scenarios where rule insertions can fail at run-time even though the static > checks during rule_construct() had passed previously. > Some possible scenarios for failure of rule insertions: > **) Rule insertions ca

Re: [ovs-dev] [ovs-discuss] ovsdb-server core dump and ovsdb corruption using raft cluster

On Wed, Jul 18, 2018 at 10:48:08AM -0700, Girish Moodalbail wrote: > Hello all, > > We are able to reproduce this issue on OVS 2.9.2 at will. The OVSDB NB > server or OVSDB SB server dumps core while it is trying to compact the > database. > > You can reproduce the issue by using: > > root@u1804

Re: [ovs-dev] [ovs-dev, 1 of 2] Revert "dpif-netdev: Use compatible function type to fix broken build."

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. build: mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I ./include

Re: [ovs-dev] [PATCH 2/2] Revert "dpctl: Expand the flow dump type filter"

> On Jul 25, 2018, at 2:11 PM, Ben Pfaff wrote: > > On Wed, Jul 25, 2018 at 02:01:32PM -0700, Justin Pettit wrote: >> Commit ab15e70eb587 ("dpctl: Expand the flow dump type filter") had a >> number of issues with style, build breakage, and failing unit tests. >> The patch is being reverted so t

Re: [ovs-dev] [PATCH] dpctl: Expand the flow dump type filter

> On Jul 25, 2018, at 9:17 AM, Simon Horman wrote: > > On Thu, Jul 12, 2018 at 09:46:40AM +0300, Roi Dayan wrote: >> >> it could. >> currently offload unit tests in the repo fail and needs an update >> though they cannot be fixed because they use veth and test dump >> using type=offloaded to

Re: [ovs-dev] [PATCH 2/2] Revert "dpctl: Expand the flow dump type filter"

On Wed, Jul 25, 2018 at 02:01:32PM -0700, Justin Pettit wrote: > Commit ab15e70eb587 ("dpctl: Expand the flow dump type filter") had a > number of issues with style, build breakage, and failing unit tests. > The patch is being reverted so that they can addressed. > > This reverts commit ab15e70eb5

[ovs-dev] [PATCH 2/2] Revert "dpctl: Expand the flow dump type filter"

Commit ab15e70eb587 ("dpctl: Expand the flow dump type filter") had a number of issues with style, build breakage, and failing unit tests. The patch is being reverted so that they can addressed. This reverts commit ab15e70eb5878b46f8f84da940ffc915b6d74cad. CC: Gavi Teitz CC: Simon Horman CC: Ro

[ovs-dev] [PATCH 1/2] Revert "dpif-netdev: Use compatible function type to fix broken build."

Commit ab15e70eb587 ("dpctl: Expand the flow dump type filter") will be reverted, which this patch fixed, so it needs to be reverted as well. This reverts commit b10ac772218afd4f296db866f6b80258e1d1ca8a. CC: Gavi Teitz CC: Simon Horman CC: Roi Dayan CC: Aaron Conole Signed-off-by: Justin Pett

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

After installing openvswitch-switch-dpdk I am getting this error. WARN[0041] Unable to locate plugin: openvswitch, retrying in 1s WARN[0042] Unable to locate plugin: openvswitch, retrying in 2s WARN[0044] Unable to locate plugin: openvswitch, retrying in 4s WARN[0048] Unable to locate plugin: open

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

Hello Guru, I am using sudo apt install openvswitch-switch-dpdk as suggested by the website. So it installed 2.5.4 by default. Do you want me to build and install OVS? https://software.intel.com/en-us/articles/using-docker-containers-with-open-vswitch-and-dpdk-on-ubuntu-1710 Regards, Sandeep On

Re: [ovs-dev] [PATCH] faq: Add explanation of Signed-off-by.

On Wed, Jul 25, 2018 at 09:57:44AM -0700, Gregory Rose wrote: > On 7/24/2018 4:46 PM, Ben Pfaff wrote: > >Suitable for cutting and pasting into explanatory emails. > > > >Signed-off-by: Ben Pfaff > >--- > > Documentation/faq/contributing.rst | 28 > > 1 file changed,

Re: [ovs-dev] dpif-netdev: compatible function type

Bleep bloop. Greetings Aaron Conole, 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: 43, Warnings: 0,

Re: [ovs-dev] [PATCH v2] tc: Fix sparse warnings.

On Wed, Jul 25, 2018 at 03:34:52PM -0400, Aaron Conole wrote: > Ben Pfaff writes: > > > Fixes the following warnings: > > > > ../lib/tc.c:817:37: error: incorrect type in assignment (different base > > types) > > ../lib/tc.c:817:37:expected restricted ovs_be16 [usertype] > > vlan_pu

Re: [ovs-dev] [PATCH v2] tc: Fix sparse warnings.

Ben Pfaff writes: > Fixes the following warnings: > > ../lib/tc.c:817:37: error: incorrect type in assignment (different base > types) > ../lib/tc.c:817:37:expected restricted ovs_be16 [usertype] > vlan_push_tpid > ../lib/tc.c:817:37:got unsigned short > ../lib/tc.c:1522

Re: [ovs-dev] [PATCH] dpif-netdev: compatible function type

On Wed, Jul 25, 2018 at 02:22:31PM -0400, Aaron Conole wrote: > The dpif_provder flow_dump_create function signature was changed, but > the netdev dpif was not updated along with it. This generated a build > error with the following warnings: > > libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H

[ovs-dev] [PATCH] dpif-netdev: compatible function type

The dpif_provder flow_dump_create function signature was changed, but the netdev dpif was not updated along with it. This generated a build error with the following warnings: libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./lib -I ./lib -Wstrict-prototypes -Wa

[ovs-dev] [PATCH 4/4] lib/tc: Support matching on ip tunnel tos and ttl

Support matching on tos and ttl of ip tunnels for the TC data-path. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- acinclude.m4 | 10 +- include/linux/pkt_cls.h | 7 ++- lib/netdev-tc-offloads.c | 8 lib/tc.c | 30 +++

[ovs-dev] [PATCH 3/4] lib/tc: Support setting tos and ttl for TC IP tunnels

Allow to set the tos and ttl for TC tunnels. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- acinclude.m4 | 6 +++--- include/linux/tc_act/tc_tunnel_key.h | 10 -- lib/netdev-tc-offloads.c | 16 lib/tc.c

[ovs-dev] [PATCH 2/4] lib/tc: Support matching on ip tos

Add the missing code to match on ip tos when dealing with the TC data-path. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- include/openvswitch/match.h | 1 + lib/match.c | 7 +++ lib/netdev-tc-offloads.c| 6 -- lib/tc.c| 10 ++ li

[ovs-dev] [PATCH 0/4] Enable set/match of tos/ttl for IP tunnels on TC data-path

This series comes to address the case to set (encap) and match (decap) also the tos and ttl fields of TC based IP tunnels. This happens e.g due to inherit setup of tunnel port for tos or due to specific OF rule. The series is rebased over Jianbo's patches for QinQ [1] Or. [1] https://mail.openvs

[ovs-dev] [PATCH 1/4] lib/tc: Handle ttl for ipv6 too

TTL can and should be used to match on IPv6's hop-limit, fix that. Fixes: ab7ecf266b0a ('netdev-tc-offloads: Add nw_ttl matching using flower') Fixes: 0b4b5203d12e ('tc: Add ip layer ttl matching') Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- lib/netdev-tc-offloads.c | 4 ++-- lib/tc.c

Re: [ovs-dev] [PATCH] tc: Fix sparse warnings.

On Wed, Jul 25, 2018 at 11:06:55AM -0700, Ben Pfaff wrote: > Fixes the following warnings: > > ../lib/tc.c:817:37: error: incorrect type in assignment (different base > types) > ../lib/tc.c:817:37:expected restricted ovs_be16 [usertype] > vlan_push_tpid > ../lib/tc.c:817:37:g

[ovs-dev] [PATCH v2] tc: Fix sparse warnings.

Fixes the following warnings: ../lib/tc.c:817:37: error: incorrect type in assignment (different base types) ../lib/tc.c:817:37:expected restricted ovs_be16 [usertype] vlan_push_tpid ../lib/tc.c:817:37:got unsigned short ../lib/tc.c:1522:54: error: incorrect type in argum

Re: [ovs-dev] dpif-netdev: Fix zero length keys insertion to EMC.

0-day Robot writes: > Bleep bloop. Greetings Ilya Maximets, 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. > > This isn't an issue with your patch, Ilya. The current mainline has a f

[ovs-dev] [PATCH] tc: Fix sparse warnings.

Fixes the following warnings: ../lib/tc.c:817:37: error: incorrect type in assignment (different base types) ../lib/tc.c:817:37:expected restricted ovs_be16 [usertype] vlan_push_tpid ../lib/tc.c:817:37:got unsigned short ../lib/tc.c:1522:54: error: incorrect type in argum

Re: [ovs-dev] [PATCH] dpctl: Expand the flow dump type filter

On Wed, Jul 25, 2018 at 06:17:15PM +0200, Simon Horman wrote: > On Thu, Jul 12, 2018 at 09:46:40AM +0300, Roi Dayan wrote: > > > > > > On 11/07/2018 16:24, Simon Horman wrote: > > > On Sun, Jul 08, 2018 at 02:15:38PM +0300, Gavi Teitz wrote: > > >> Added new types to the flow dump filter, and all

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

We had talked about using OVS 2.9, right? Are you using that? On 25 July 2018 at 08:51, Sandeep Adapala wrote: > Hello Guru, > > I think OVS doesn't like me at all :) every step I am facing a issue. > > this time when I tried to create a docker network on OVS (*sudo docker > network create -d op

[ovs-dev] Dear Sir/Madam!

Dear Sir/Madam! We are interested in purchasing your products and we sincerely hope to establish a long-term business relation with your esteemed company. Please kindly send me your latest catalog. Also, inform me about the Minimum Order Quantity, Delivery time or FOB, and payment terms warra

Re: [ovs-dev] [PATCH] faq: Add explanation of Signed-off-by.

On 7/24/2018 4:46 PM, Ben Pfaff wrote: Suitable for cutting and pasting into explanatory emails. Signed-off-by: Ben Pfaff --- Documentation/faq/contributing.rst | 28 1 file changed, 28 insertions(+) diff --git a/Documentation/faq/contributing.rst b/Documentati

Re: [ovs-dev] dpif-netdev: Fix zero length keys insertion to EMC.

Bleep bloop. Greetings Ilya Maximets, 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. build: mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I ./include

[ovs-dev] Resize of DPDK packets (was Re: [PATCH v6 00/13] Support multi-segment mbufs)

On 24/07/2018 17:55, Ilya Maximets wrote: > Hi. > Just wanted to add some comments for the use-cases and testing methodology. > See inline. >> And I'm actually not sure if there any profit from this patch set? > It looks like an internal mbuf handling rework that only degrades > the performance and

Re: [ovs-dev] [PATCH] dpif-netdev: Fix zero length keys insertion to EMC.

Thanks Ilya for pointing it out. It should be inserted after key length calculation. Acked-by: Yipeng Wang >-Original Message- >From: Ilya Maximets [mailto:i.maxim...@samsung.com] >Sent: Wednesday, July 25, 2018 9:10 AM >To: ovs-dev@openvswitch.org; Wang, Yipeng1 >Cc: Ben Pfaff ; Stoke

Re: [ovs-dev] [PATCH v3 0/4] Add support to offload QinQ

On Tue, Jul 24, 2018 at 10:15:27AM +0200, Simon Horman wrote: > On Tue, Jul 17, 2018 at 02:01:53AM +, Jianbo Liu wrote: > > This patchset is to support QinQ offloading, as TC flower supports QinQ. > > > > v3: > > fix checkpatch warning in patch 4. > > v2: > > fix compile issue in patch

Re: [ovs-dev] [PATCH] dpctl: Expand the flow dump type filter

On Thu, Jul 12, 2018 at 09:46:40AM +0300, Roi Dayan wrote: > > > On 11/07/2018 16:24, Simon Horman wrote: > > On Sun, Jul 08, 2018 at 02:15:38PM +0300, Gavi Teitz wrote: > >> Added new types to the flow dump filter, and allowed multiple filter > >> types to be passed at once, as a comma separated

Re: [ovs-dev] [PATCH v1] rhel: support kmod build against mulitple kernel versions, fedora

On Fri, Jul 20, 2018 at 03:24:53PM -0700, Martin Xu wrote: > This patch ports changes from kmod rhel6 spec file to fedora spec file, > to support packaging kernel modules built against multiple versions of > kernel sources. > > RHEL 7.4 introduced backward incompatible changes in the kernel. As >

[ovs-dev] [PATCH] dpif-netdev: Fix zero length keys insertion to EMC.

'key.len' should be calculated before inserting to EMC, otherwise resulting entry will match with any packet with the same hash. CC: Yipeng Wang Fixes: 60d8ccae135f ("dpif-netdev: Add SMC cache after EMC cache") Signed-off-by: Ilya Maximets --- lib/dpif-netdev.c | 2 +- 1 file changed, 1 insert

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

Hello Guru, I think OVS doesn't like me at all :) every step I am facing a issue. this time when I tried to create a docker network on OVS (*sudo docker network create -d openvswitch --subnet=192.168.22.0/24 ovs*) it failed and I got this error in Docker log *ERRO[2717]

Re: [ovs-dev] [PATCH] compat: Initialize IPv4 reassembly secret timer

On 7/23/2018 9:22 AM, Yi-Hung Wei wrote: --- a/datapath/linux/compat/ip_fragment.c +++ b/datapath/linux/compat/ip_fragment.c @@ -812,6 +812,9 @@ int __init rpl_ipfrag_init(void) #ifdef HAVE_INET_FRAGS_WITH_FRAGS_WORK ip4_frags.frags_cache_name = ip_frag_cache_name; #endif +#if RHE

Re: [ovs-dev] [PATCH 4/4] [RFC] ovn-nbctl: Make daemon mode more transparent.

On Tue, Jul 24, 2018 at 07:53 PM GMT, Ben Pfaff wrote: > This has some flaws in the details; for example, command-line options > parsing is very inflexible. > > Signed-off-by: Ben Pfaff > --- Thank you for working on this. I hooked it up to ovn-nbct.at test suite and it worked quite nicely. Only

[ovs-dev] [PATCH] ovn-nbctl: Detect unrecognized short options in server mode.

Because getopt() will set optopt for both known and unknown options, we need to differentiate between them ourselves by checking if we know the option. Do that by looking up its value. Also, because we are using GNU extensions to getopt(), we need to be resetting getopt() state by setting optind t

Re: [ovs-dev] Revert "dp-packet: Handle multi-seg mbufs in resize__()."

On 7/25/2018 2:56 PM, Aaron Conole wrote: 0-day Robot writes: Bleep bloop. Greetings Tiago Lam, 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. Hi Ian (and all), Given there are currentl

[ovs-dev] [PATCH v7 11/13] 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 instance

[ovs-dev] [PATCH v7 12/13] 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_DPDK_STAR

[ovs-dev] [PATCH v7 13/13] 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 c

[ovs-dev] [PATCH v7 10/13] 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 ne

[ovs-dev] [PATCH v7 09/13] 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 dat

[ovs-dev] [PATCH v7 08/13] 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 p

[ovs-dev] [PATCH v7 07/13] 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, dp_p

[ovs-dev] [PATCH v7 05/13] dp-packet: Fix data_len handling multi-seg mbufs.

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 considered while distributing the new (provided) size. To account for the above dp_packet_set_size() has bee

[ovs-dev] [PATCH v7 06/13] 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 exam

[ovs-dev] [PATCH v7 04/13] 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 Acked-by: Eelco Chaudron --- lib/netdev-dpdk.c | 35 +++

[ovs-dev] [PATCH v7 03/13] 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, whic

[ovs-dev] [PATCH v7 02/13] 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 unexpec

[ovs-dev] [PATCH v7 00/13] 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 'segment'

[ovs-dev] [PATCH v7 01/13] 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, mbu

[ovs-dev] [PATCH 1/1] ovn-nbctl: Initialize arguments to avoid compilation warnings.

Output arguments for parse_priority() and dhcp_options_get() may not be initialized when either function returns an error. This causes compilation warnings for GCC 6.3.x regarding use of uninitialized variable use and null-pointer-arithmetic. Fix this by initializing priority_p* value to 0 for pr

Re: [ovs-dev] [ovs-dev, RFC] dp-packet: Don't resize DPBUF_DPDK packets.

0-day Robot writes: > Bleep bloop. Greetings Tiago Lam, 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. > > Sorry for the noise. The robot was improperly matching the RFC tag (so ''PA

Re: [ovs-dev] Revert "dp-packet: Handle multi-seg mbufs in resize__()."

0-day Robot writes: > Bleep bloop. Greetings Tiago Lam, 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. > Hi Ian (and all), Given there are currently two trees (mainline and dpdk_merg

Re: [ovs-dev] [PATCH] netlink-conntrack: undef the correct macro

Ben Pfaff writes: > On Mon, Jul 23, 2018 at 04:40:49PM -0400, Aaron Conole wrote: >> Fixes: 6830a0c0e6bf ("netlink-conntrack: New module.") >> Cc: Daniele Di Proietto >> Signed-off-by: Aaron Conole > > Thanks, applied to master. > > I didn't backport because I don't think there's any real harm

Re: [ovs-dev] [ovs-discuss] ovsdb-server core dump and ovsdb corruption using raft cluster

On one occasion, we saw ovsdb-server crash with a similar stack (i.e., at the same location but different code path). This time, the raft node (leader) was trying to reply to a follower with a snapshot of its database (I am guessing from the stack trace, so I might be way off here). See below, for