Hello,
I am trying to build a simplified version of the "sample L2
transparent network service chaining implementation" described in
section 6 of this document
https://www.opennetworking.org/wp-content/uploads/2014/10/L4-L7_Service_Function_Chaining_Solution_Architecture.pdf.
My simplifications:
Solved this one, and here is what I have done in case it may be
helpful to someone.
My setup is a derivative of
http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/,
where I am using a single ovs bridge per node and connect the ovs
bridges of each node via VETH pairs instead. The
DPDK. SRIOV and any sort of Smart NIC which removes or obfuscates the
generic kernel packet path from view have their place. But they are
all stop gap technologies IMNSHO.
eBPF + XDP plugged into OVS is in my view the only truly useful use
case worth pursuing for SDN workload interaction.
If
Thanks for the response all.
@Ian
1GB pagesize, 8 total pages. OVS is launched without the
dpdk-socket-mem options so it should take 1GB. When one switch is
started, free hugepage count drops to 7. When I launch another, I'd
expect it to drop to 6 but it crashes instead.
My DPDK apps create the
I was asked in an OVN meeting to send out an email talking about what
we're working on to make ovn-northd and ovn-controller faster. Here's
my summary.
OVN is essentially a stack of compilers. At the top, the CMS dumps
some configuration into the northbound database (NDBB). Then:
1.
Thanks for sharing. Yes - I have heard of some folks using Mellanox
cards. But, I was more curious about use of Intel FM1 series - FM10420
and FM10840 chipset which Silicom and I think Lanner also has these cards
with OVS.
Thanks
On Fri, Nov 2, 2018 at 4:35 AM wrote:
> Thank you very
Thank you very much for the slides,
Hmm the presentation doesn’t actually have much detail on why the upper bound
is ~30G (I guess per port), well with 6 cores anyways, using the slow x86 path.
So is the point you’re trying to make that above 40G per port one needs to
enter the realm of
Have a look at :
https://m.youtube.com/watch?v=MglrK-JTiqc
Disclaimer I worked for Nuage at the time that was done, and work for
Redhat now.
On Fri, 2 Nov 2018, 22:23 > boun...@openvswitch.org] On Behalf Of Joel Wiramu Pauling
> > Sent: Thursday, November 01, 2018 10:29 PM
> >
> > Currently
> boun...@openvswitch.org] On Behalf Of Joel Wiramu Pauling
> Sent: Thursday, November 01, 2018 10:29 PM
>
> Currently - doing slow-path through commodity x86 silicon you are pretty
> much capped at 40gbit; so beyond a few use cases where you are say
> writting to an NVME array directly within