Re: [vpp-dev] Request: please add "real" pcap ability #vpp
Thanks for the update. Feel free to contribute to the documentation or wiki on that point Jerome De : au nom de Brian Dickson Date : dimanche 25 novembre 2018 à 19:36 À : Jerome Tollet Cc : "vpp-dev@lists.fd.io" Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp Hi, Jerome (and everyone), Thanks for this! Using packet-capture + span, did indeed accomplish what I was looking for. One useful data point: I was able to capture about 10 seconds of line-rate 10G into a pcap file, and it looks like I didn't lose any packets, on a VPP host that was not forwarding packets. Thanks again, Brian On Fri, Nov 23, 2018 at 9:06 AM Jerome Tollet (jtollet) mailto:jtol...@cisco.com>> wrote: Hi Brian, I tried what I told you and I confirm that worked fine on my setup. create packet-generator interface pg0 packet-generator capture pg0 pcap /tmp/mycap.pcap set interface span SOURCE_INTF destination pg0 set interface state pg0 up Jerome De : mailto:vpp-dev@lists.fd.io>> au nom de Brian Dickson mailto:brian.peter.dick...@gmail.com>> Date : vendredi 23 novembre 2018 à 08:03 À : "d...@barachs.net<mailto:d...@barachs.net>" mailto:d...@barachs.net>> Cc : "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" mailto:vpp-dev@lists.fd.io>> Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp On Thu, Nov 22, 2018 at 5:30 AM mailto:d...@barachs.net>> wrote: Laying aside comments about folks who aren’t regular community contributors introducing themselves in random ways, here are a few thoughts: We have a plan to unify pcap tracepoints when Damjan finishes reworking the ethernet input node. That is very welcome news. Is there a rough timeline for Damjan's reworking, and the unification? I just want to factor that into my own plans, if possible. No matter what, pcap capture involves a bunch of data copying. The forwarding rate will clearly suffer. Full stop. Yes, I fully understand that. There's no such thing as a free lunch. In the environment in question, there's VPP hosts (doing BGP with the netlink and router sandbox plugins to get the routing table into VPP), and adjacent to them (physically upstream/downstream) we are using passive optical splitters. Those optical splitters feed copies of traffic to capture hosts, specifically dedicated to packet capture and/or other integrated analysis code to be developed. Our packet capture would only be using VPP without any packet forwarding, i.e. as a convenient way of integrating kernel offload with packet capture, and possibly chained with other added custom nodes. (DPDK by itself is not really friendly for doing any kind of from-scratch integration, and I haven't found many/any other currently maintained open source packages/frameworks that offer pcap. E.g. netmap-libpcap seems abandoned.) Having the ability to add other nodes in the graph, that do other stuff, possibly with zero copy, is another major reason we're looking at VPP. So, pcap is the starting point, and future work might keep the pcap capability (assuming the ability to control whether capture is done, and the ability to specify pcap filter rules), and add other custom functionality. To give you an idea, this is not consumer-grade stuff we are using; 12 or 24 core Intel boxes (with HT, appears as 24 or 48 cores), and 128GB or 256GB of memory, just for packet capture, onto RAIDed SSDs. Thanks for the info, and I'll definitely look at that extras/wireshark thing. Brian In master/latest, I’ve added pcap tracing – and a wireshark dissector – to the graph dispatch engine. See .../extras/wireshark/readme.md for more detail. The wireshark dissector isn’t finished by any means, nor do we have a blessed encap type number from tcpdump-workers, nor is the work upstreamed into wireshark. Erreur ! Nom du fichier non spécifié. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> On Behalf Of brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com> Sent: Wednesday, November 21, 2018 6:59 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Request: please add "real" pcap ability #vpp Hi, dev folks, Apologies for my first message being kind of demanding. However, I think this is a reasonable request. What I am interested in, and I think this is likely to be a fairly universal desire, is the ability to properly integrate some kind of pcap packet capture to the full VPP graph. The current available mechanisms (pcap drop trace and pcap tx trace) do not apply to packets that are only "handled" by the host in question, i.e. neither originate or terminate on the local host. In particular, I'm interested in something that can run on a bare metal host and, presuming sufficient resources can be given to it (cores, memory, etc), do packet capture
Re: [vpp-dev] Request: please add "real" pcap ability #vpp
Hi, Jerome (and everyone), Thanks for this! Using packet-capture + span, did indeed accomplish what I was looking for. One useful data point: I was able to capture about 10 seconds of line-rate 10G into a pcap file, and it looks like I didn't lose any packets, on a VPP host that was not forwarding packets. Thanks again, Brian On Fri, Nov 23, 2018 at 9:06 AM Jerome Tollet (jtollet) wrote: > Hi Brian, > > I tried what I told you and I confirm that worked fine on my setup. > > > > *create packet-generator interface pg0* > > *packet-generator capture pg0 pcap /tmp/mycap.pcap* > > *set interface span SOURCE_INTF destination pg0* > > *set interface state pg0 up* > > > > Jerome > > *De : * au nom de Brian Dickson < > brian.peter.dick...@gmail.com> > *Date : *vendredi 23 novembre 2018 à 08:03 > *À : *"d...@barachs.net" > *Cc : *"vpp-dev@lists.fd.io" > *Objet : *Re: [vpp-dev] Request: please add "real" pcap ability #vpp > > > > > > On Thu, Nov 22, 2018 at 5:30 AM wrote: > > Laying aside comments about folks who aren’t regular community > contributors introducing themselves in random ways, here are a few thoughts: > > > > We have a plan to unify pcap tracepoints when Damjan finishes reworking > the ethernet input node. > > > > That is very welcome news. > > > > Is there a rough timeline for Damjan's reworking, and the unification? I > just want to factor that into my own plans, if possible. > > > > > > No matter what, pcap capture involves a bunch of data copying. The > forwarding rate will clearly suffer. Full stop. > > > > Yes, I fully understand that. There's no such thing as a free lunch. > > > > In the environment in question, there's VPP hosts (doing BGP with the > netlink and router sandbox plugins to get the routing table into VPP), and > adjacent to them (physically upstream/downstream) we are using passive > optical splitters. > > > > Those optical splitters feed copies of traffic to capture hosts, > specifically dedicated to packet capture and/or other integrated analysis > code to be developed. > > > > Our packet capture would only be using VPP without any packet forwarding, > i.e. as a convenient way of integrating kernel offload with packet capture, > and possibly chained with other added custom nodes. > > > > (DPDK by itself is not really friendly for doing any kind of from-scratch > integration, and I haven't found many/any other currently maintained open > source packages/frameworks that offer pcap. E.g. netmap-libpcap seems > abandoned.) > > > > Having the ability to add other nodes in the graph, that do other stuff, > possibly with zero copy, is another major reason we're looking at VPP. > > > > So, pcap is the starting point, and future work might keep the pcap > capability (assuming the ability to control whether capture is done, and > the ability to specify pcap filter rules), and add other custom > functionality. > > > > To give you an idea, this is not consumer-grade stuff we are using; 12 or > 24 core Intel boxes (with HT, appears as 24 or 48 cores), and 128GB or > 256GB of memory, just for packet capture, onto RAIDed SSDs. > > > > Thanks for the info, and I'll definitely look at that extras/wireshark > thing. > > > > Brian > > > > > > In master/latest, I’ve added pcap tracing – and a wireshark dissector – to > the graph dispatch engine. See .../extras/wireshark/readme.md for more > detail. The wireshark dissector isn’t finished by any means, nor do we have > a blessed encap type number from tcpdump-workers, nor is the work > upstreamed into wireshark. > > > > [image: cid:image001.png@01D4823D.97D176D0] > > > > > > > > *From:* vpp-dev@lists.fd.io *On Behalf Of * > brian.peter.dick...@gmail.com > *Sent:* Wednesday, November 21, 2018 6:59 PM > *To:* vpp-dev@lists.fd.io > *Subject:* [vpp-dev] Request: please add "real" pcap ability #vpp > > > > Hi, dev folks, > > Apologies for my first message being kind of demanding. > > However, I think this is a reasonable request. > > What I am interested in, and I think this is likely to be a fairly > universal desire, is the ability to properly integrate some kind of pcap > packet capture to the full VPP graph. > > The current available mechanisms (pcap drop trace and pcap tx trace) do > not apply to packets that are only "handled" by the host in question, i.e. > neither originate or terminate on the local host. > > In particular, I'm interested in something that can run on a bare metal > host and, presuming sufficient resources
Re: [vpp-dev] Request: please add "real" pcap ability #vpp
Hi Brian,
I tried what I told you and I confirm that worked fine on my setup.
create packet-generator interface pg0
packet-generator capture pg0 pcap /tmp/mycap.pcap
set interface span SOURCE_INTF destination pg0
set interface state pg0 up
Jerome
De : au nom de Brian Dickson
Date : vendredi 23 novembre 2018 à 08:03
À : "d...@barachs.net"
Cc : "vpp-dev@lists.fd.io"
Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp
On Thu, Nov 22, 2018 at 5:30 AM mailto:d...@barachs.net>>
wrote:
Laying aside comments about folks who aren’t regular community contributors
introducing themselves in random ways, here are a few thoughts:
We have a plan to unify pcap tracepoints when Damjan finishes reworking the
ethernet input node.
That is very welcome news.
Is there a rough timeline for Damjan's reworking, and the unification? I just
want to factor that into my own plans, if possible.
No matter what, pcap capture involves a bunch of data copying. The forwarding
rate will clearly suffer. Full stop.
Yes, I fully understand that. There's no such thing as a free lunch.
In the environment in question, there's VPP hosts (doing BGP with the netlink
and router sandbox plugins to get the routing table into VPP), and adjacent to
them (physically upstream/downstream) we are using passive optical splitters.
Those optical splitters feed copies of traffic to capture hosts, specifically
dedicated to packet capture and/or other integrated analysis code to be
developed.
Our packet capture would only be using VPP without any packet forwarding, i.e.
as a convenient way of integrating kernel offload with packet capture, and
possibly chained with other added custom nodes.
(DPDK by itself is not really friendly for doing any kind of from-scratch
integration, and I haven't found many/any other currently maintained open
source packages/frameworks that offer pcap. E.g. netmap-libpcap seems
abandoned.)
Having the ability to add other nodes in the graph, that do other stuff,
possibly with zero copy, is another major reason we're looking at VPP.
So, pcap is the starting point, and future work might keep the pcap capability
(assuming the ability to control whether capture is done, and the ability to
specify pcap filter rules), and add other custom functionality.
To give you an idea, this is not consumer-grade stuff we are using; 12 or 24
core Intel boxes (with HT, appears as 24 or 48 cores), and 128GB or 256GB of
memory, just for packet capture, onto RAIDed SSDs.
Thanks for the info, and I'll definitely look at that extras/wireshark thing.
Brian
In master/latest, I’ve added pcap tracing – and a wireshark dissector – to the
graph dispatch engine. See .../extras/wireshark/readme.md for more detail. The
wireshark dissector isn’t finished by any means, nor do we have a blessed encap
type number from tcpdump-workers, nor is the work upstreamed into wireshark.
[cid:image001.png@01D4823D.97D176D0]
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> On Behalf Of
brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>
Sent: Wednesday, November 21, 2018 6:59 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Request: please add "real" pcap ability #vpp
Hi, dev folks,
Apologies for my first message being kind of demanding.
However, I think this is a reasonable request.
What I am interested in, and I think this is likely to be a fairly universal
desire, is the ability to properly integrate some kind of pcap packet capture
to the full VPP graph.
The current available mechanisms (pcap drop trace and pcap tx trace) do not
apply to packets that are only "handled" by the host in question, i.e. neither
originate or terminate on the local host.
In particular, I'm interested in something that can run on a bare metal host
and, presuming sufficient resources can be given to it (cores, memory, etc), do
packet capture at line rate.
Thus, any restriction ("run it on a VM") is not adequate.
Given that there is already stuff for handling the pcap file already (in
vnet/unix IIRC), this should not be a lot of work.
There are two use cases I have:
· debugging data plane stuff on a vpp-based router (i.e. using the vppsb
netlink and router projects)
· packet capture at line rate (a vpp host that only listens/drops traffic,
incidental to the packet capture, i.e. a single-purpose host, bypassing
kernel/driver limitations, to take all ethernet traffic on a port and stuff it
into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures
using RSS/RFS to multiple cores and having each core be a thread doing pcap
file writing; how that would be put into the "vpp graph" might be a little less
than trivial, but should be straightforward, IMHO)
Thanks in advance.
Brian Dickson
P.S. There is a SERIOUS l
Re: [vpp-dev] Request: please add "real" pcap ability #vpp
I tried in the past and that was working fine.
Jerome
De : Brian Dickson
Date : vendredi 23 novembre 2018 à 07:44
À : Jerome Tollet
Cc : "vpp-dev@lists.fd.io"
Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp
On Thu, Nov 22, 2018 at 8:18 AM Jerome Tollet (jtollet)
mailto:jtol...@cisco.com>> wrote:
Hi Peter,
(It's actually Brian, BTW.)
Did you try creating a pg interface and spanning packet from your port to this
interface?
I didn't, there wasn't a lot of documentation that would have pointed in that
direction.
But, I will, thanks for the suggestion.
Brian
Jerome
De : mailto:vpp-dev@lists.fd.io>> au nom de
"brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>"
mailto:brian.peter.dick...@gmail.com>>
Date : jeudi 22 novembre 2018 à 00:58
À : "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] Request: please add "real" pcap ability #vpp
Hi, dev folks,
Apologies for my first message being kind of demanding.
However, I think this is a reasonable request.
What I am interested in, and I think this is likely to be a fairly universal
desire, is the ability to properly integrate some kind of pcap packet capture
to the full VPP graph.
The current available mechanisms (pcap drop trace and pcap tx trace) do not
apply to packets that are only "handled" by the host in question, i.e. neither
originate or terminate on the local host.
In particular, I'm interested in something that can run on a bare metal host
and, presuming sufficient resources can be given to it (cores, memory, etc), do
packet capture at line rate.
Thus, any restriction ("run it on a VM") is not adequate.
Given that there is already stuff for handling the pcap file already (in
vnet/unix IIRC), this should not be a lot of work.
There are two use cases I have:
• debugging data plane stuff on a vpp-based router (i.e. using the
vppsb netlink and router projects)
• packet capture at line rate (a vpp host that only listens/drops
traffic, incidental to the packet capture, i.e. a single-purpose host,
bypassing kernel/driver limitations, to take all ethernet traffic on a port and
stuff it into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures
using RSS/RFS to multiple cores and having each core be a thread doing pcap
file writing; how that would be put into the "vpp graph" might be a little less
than trivial, but should be straightforward, IMHO)
Thanks in advance.
Brian Dickson
P.S. There is a SERIOUS lack of useful documentation on how to actually do
this, as a potential ad-hoc contributor. Not sure if you guys have gotten this
feedback from anyone else.
P.P.S. I'm using 18.07 because that is the last version that builds alongside
the vppsb netlink and router plugins.
P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should try
doing this from scratch, i.e. put yourselves in the shoes of someone who just
discovered vpp...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11376): https://lists.fd.io/g/vpp-dev/message/11376
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Request: please add "real" pcap ability #vpp
On Thu, Nov 22, 2018 at 8:18 AM Jerome Tollet (jtollet)
wrote:
> Hi Peter,
>
(It's actually Brian, BTW.)
> Did you try creating a pg interface and spanning packet from your port to
> this interface?
>
I didn't, there wasn't a lot of documentation that would have pointed in
that direction.
But, I will, thanks for the suggestion.
Brian
> Jerome
>
>
>
> *De : * au nom de "brian.peter.dick...@gmail.com" <
> brian.peter.dick...@gmail.com>
> *Date : *jeudi 22 novembre 2018 à 00:58
> *À : *"vpp-dev@lists.fd.io"
> *Objet : *[vpp-dev] Request: please add "real" pcap ability #vpp
>
>
>
> Hi, dev folks,
>
> Apologies for my first message being kind of demanding.
>
> However, I think this is a reasonable request.
>
> What I am interested in, and I think this is likely to be a fairly
> universal desire, is the ability to properly integrate some kind of pcap
> packet capture to the full VPP graph.
>
> The current available mechanisms (pcap drop trace and pcap tx trace) do
> not apply to packets that are only "handled" by the host in question, i.e.
> neither originate or terminate on the local host.
>
> In particular, I'm interested in something that can run on a bare metal
> host and, presuming sufficient resources can be given to it (cores, memory,
> etc), do packet capture at line rate.
>
> Thus, any restriction ("run it on a VM") is not adequate.
>
> Given that there is already stuff for handling the pcap file already (in
> vnet/unix IIRC), this should not be a lot of work.
>
> There are two use cases I have:
>
> · debugging data plane stuff on a vpp-based router (i.e. using
> the vppsb netlink and router projects)
>
> · packet capture at line rate (a vpp host that only listens/drops
> traffic, incidental to the packet capture, i.e. a single-purpose host,
> bypassing kernel/driver limitations, to take all ethernet traffic on a port
> and stuff it into a pcap file.)
>
> oNB: for scaling purposes, it is reasonable to implement the pcap
> captures using RSS/RFS to multiple cores and having each core be a thread
> doing pcap file writing; how that would be put into the "vpp graph" might
> be a little less than trivial, but should be straightforward, IMHO)
>
> Thanks in advance.
>
> Brian Dickson
>
> P.S. There is a SERIOUS lack of useful documentation on how to actually do
> this, as a potential ad-hoc contributor. Not sure if you guys have gotten
> this feedback from anyone else.
> P.P.S. I'm using 18.07 because that is the last version that builds
> alongside the vppsb netlink and router plugins.
> P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should
> try doing this from scratch, i.e. put yourselves in the shoes of someone
> who just discovered vpp...
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11374): https://lists.fd.io/g/vpp-dev/message/11374
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Request: please add "real" pcap ability #vpp
Hi Peter,
Did you try creating a pg interface and spanning packet from your port to this
interface?
Jerome
De : au nom de "brian.peter.dick...@gmail.com"
Date : jeudi 22 novembre 2018 à 00:58
À : "vpp-dev@lists.fd.io"
Objet : [vpp-dev] Request: please add "real" pcap ability #vpp
Hi, dev folks,
Apologies for my first message being kind of demanding.
However, I think this is a reasonable request.
What I am interested in, and I think this is likely to be a fairly universal
desire, is the ability to properly integrate some kind of pcap packet capture
to the full VPP graph.
The current available mechanisms (pcap drop trace and pcap tx trace) do not
apply to packets that are only "handled" by the host in question, i.e. neither
originate or terminate on the local host.
In particular, I'm interested in something that can run on a bare metal host
and, presuming sufficient resources can be given to it (cores, memory, etc), do
packet capture at line rate.
Thus, any restriction ("run it on a VM") is not adequate.
Given that there is already stuff for handling the pcap file already (in
vnet/unix IIRC), this should not be a lot of work.
There are two use cases I have:
· debugging data plane stuff on a vpp-based router (i.e. using the
vppsb netlink and router projects)
· packet capture at line rate (a vpp host that only listens/drops
traffic, incidental to the packet capture, i.e. a single-purpose host,
bypassing kernel/driver limitations, to take all ethernet traffic on a port and
stuff it into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures
using RSS/RFS to multiple cores and having each core be a thread doing pcap
file writing; how that would be put into the "vpp graph" might be a little less
than trivial, but should be straightforward, IMHO)
Thanks in advance.
Brian Dickson
P.S. There is a SERIOUS lack of useful documentation on how to actually do
this, as a potential ad-hoc contributor. Not sure if you guys have gotten this
feedback from anyone else.
P.P.S. I'm using 18.07 because that is the last version that builds alongside
the vppsb netlink and router plugins.
P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should try
doing this from scratch, i.e. put yourselves in the shoes of someone who just
discovered vpp...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11373): https://lists.fd.io/g/vpp-dev/message/11373
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Request: please add "real" pcap ability #vpp
Hi, dev folks,
Apologies for my first message being kind of demanding.
However, I think this is a reasonable request.
What I am interested in, and I think this is likely to be a fairly universal
desire, is the ability to properly integrate some kind of pcap packet capture
to the full VPP graph.
The current available mechanisms (pcap drop trace and pcap tx trace) do not
apply to packets that are only "handled" by the host in question, i.e. neither
originate or terminate on the local host.
In particular, I'm interested in something that can run on a bare metal host
and, presuming sufficient resources can be given to it (cores, memory, etc), do
packet capture at line rate.
Thus, any restriction ("run it on a VM") is not adequate.
Given that there is already stuff for handling the pcap file already (in
vnet/unix IIRC), this should not be a lot of work.
There are two use cases I have:
* debugging data plane stuff on a vpp-based router (i.e. using the vppsb
netlink and router projects)
* packet capture at line rate (a vpp host that only listens/drops traffic,
incidental to the packet capture, i.e. a single-purpose host, bypassing
kernel/driver limitations, to take all ethernet traffic on a port and stuff it
into a pcap file.)
* NB: for scaling purposes, it is reasonable to implement the pcap captures
using RSS/RFS to multiple cores and having each core be a thread doing pcap
file writing; how that would be put into the "vpp graph" might be a little less
than trivial, but should be straightforward, IMHO)
Thanks in advance.
Brian Dickson
P.S. There is a SERIOUS lack of useful documentation on how to actually do
this, as a potential ad-hoc contributor. Not sure if you guys have gotten this
feedback from anyone else.
P.P.S. I'm using 18.07 because that is the last version that builds alongside
the vppsb netlink and router plugins.
P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should try
doing this from scratch, i.e. put yourselves in the shoes of someone who just
discovered vpp...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11359): https://lists.fd.io/g/vpp-dev/message/11359
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
