A couple of month ago, I proposed a fix for over-MTU-sized vxlan
packet loss at link[1], neither by fragmenting the tunnelled vxlan
packet, nor pushing back PMTU ICMP need fragmented message is
accepted by community. The upstream workaround is by adjusting
guest mtu smaller or host mtu bigger, or
On 02/03/15 at 05:55pm, Jesse Gross wrote:
> On Tue, Feb 3, 2015 at 3:18 PM, Jesse Gross wrote:
> > It seems like in general userspace should not allow different
> > extensions to share the same datapath port. This perhaps isn't much of
> > an issue right now but if you enable an extension on one
On 02/03/15 at 10:09am, Pravin Shelar wrote:
> When I tried this patch series against mainline 3.19-rc7, I got
> following error on insert.
>
> openvswitch: Unknown symbol rpl_vxlan_xmit_skb (err 0)
> openvswitch: Unknown symbol rpl_vxlan_sock_release (err 0)
> openvswitch: Unknown symbol rpl_vxla
On Tuesday, February 03, 2015 04:07:24 PM Ben Pfaff wrote:
> On Tue, Jan 20, 2015 at 01:20:56PM -0200, Flavio Leitner wrote:
> > The struct mcast_fport_bundle will be used for ports
> > forwarding Reports too, so make it generic.
> >
> > Signed-off-by: Flavio Leitner
>
> I apologize that it has
Current flow commands: new, set, get, del need to respond with a NETLINK
error in the case OVS_FLOW_ATTR_KEY is missing.
OVS_FLOW_ATTR_KEY is now an optional attribute.
Also add OVS_FLOW_ATTR_UFID attribute to the kernel for further use.
v2 Remove redundant return code
Acked-by: Eitan Eliahu
Current flow commands: new, set, get, del need to respond with a NETLINK
error in the case OVS_FLOW_ATTR_KEY is missing.
OVS_FLOW_ATTR_KEY is now an optional attribute.
Also add OVS_FLOW_ATTR_UFID attribute to the kernel for further use.
v3 Fix broken commit
v2 Remove redundant return code
Ack
I've read through this thread and although there was a lot of discussion
about OVN and
integration with OpenStack I'd like to ask if there has been any discussion
about what
considerations might need to be made tomake OVN easy to utilize with Linux
Containers/Namespaces?
Use of container technolog
On Wed, Feb 4, 2015 at 6:40 AM, brian mullan wrote:
> I've read through this thread and although there was a lot of discussion
> about OVN and
> integration with OpenStack I'd like to ask if there has been any discussion
> about what
> considerations might need to be made tomake OVN easy to utiliz
Inspired by Ben Pfaff's email on 32 bit build environment, this adds a
32bit build to the travis build matrix to catch alignment and padding
issues.
The 32 bit build is only enabled for non-DPDK builds as DPDK itself is
currently not capable to be compiled with -m32.
The build also has SSL disabl
v4:
- Pushed already ACKed patches if no dependencies remained
- Addressed Pravin's feedback:
- Fixed missing symbols if VXLAN compat stack is needed
- Only set TUNNEL_VXLAN_OPT if VXLAN metadata was found in the packet
- Addressed Ben's feedback (Fixed by Madhu Challa):
- Fixed manual
Fixes an insufficient ifdef in compat/vxlan.c which caused required
symbols not to be included in the build. The declarations were properly
enabled so the build would succeed but the module would spit missing
symbols when being inserted.
The fix uses a new define USE_UPSTREAM_VXLAN which is set in
Upstream commit:
openvswitch: Support VXLAN Group Policy extension
Introduces support for the group policy extension to the VXLAN virtual
port. The extension is disabled by default and only enabled if the user
has provided the respective configuration.
ovs-vsctl add-port br0
Excludes VXLAN_F_REMCSUM_TX bits as OVS currently doesn't support it.
Upstream commit:
vxlan: Eliminate dependency on UDP socket in transmit path
In the vxlan transmit path there is no need to reference the socket
for a tunnel which is needed for the receive side. We do, however,
Signed-off-by: Thomas Graf
---
FAQ.md | 1 +
NEWS | 2 +-
acinclude.m4 | 4 ++--
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/FAQ.md b/FAQ.md
index 02fe2d3..2de4936 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -147,6 +147,7 @@ A: The following table lists the Linux kernel v
From: Madhu Challa
Introduces two new NXMs to represent VXLAN-GBP [0] fields.
actions=load:0x10->NXM_NX_TUN_GBP_ID[],NORMAL
tun_gbp_id=0x10,actions=drop
This enables existing VXLAN tunnels to carry security label
information such as a SELinux context to other network peers.
The values are
Supports a new "exts" field in the tunnel configuration which takes a
comma separated list of enabled extensions.
The only extension supported so far is GBP but this can be used to
enable RCO and possibly others as soon as the OVS datapath supports
them.
Signed-off-by: Thomas Graf
Acked-by: Ben
On Wed, Feb 04, 2015 at 04:10:59PM +0100, Thomas Graf wrote:
> Inspired by Ben Pfaff's email on 32 bit build environment, this adds a
> 32bit build to the travis build matrix to catch alignment and padding
> issues.
>
> The 32 bit build is only enabled for non-DPDK builds as DPDK itself is
> curre
On Wed, Feb 04, 2015 at 11:07:05AM -0200, Flavio Leitner wrote:
> On Tuesday, February 03, 2015 04:07:24 PM Ben Pfaff wrote:
> > On Tue, Jan 20, 2015 at 01:20:56PM -0200, Flavio Leitner wrote:
> > > The struct mcast_fport_bundle will be used for ports
> > > forwarding Reports too, so make it generi
On Wed, Feb 04, 2015 at 09:57:34AM -0800, Ben Pfaff wrote:
> On Wed, Feb 04, 2015 at 11:07:05AM -0200, Flavio Leitner wrote:
> > On Tuesday, February 03, 2015 04:07:24 PM Ben Pfaff wrote:
> > > On Tue, Jan 20, 2015 at 01:20:56PM -0200, Flavio Leitner wrote:
> > > > The struct mcast_fport_bundle wil
On Fri, Jan 23, 2015 at 9:33 AM, Gurucharan Shetty wrote:
> On Thu, Jan 22, 2015 at 9:19 PM, Ben Pfaff wrote:
>> The travis autobuilder has been pretty awesome for GNU/Linux continuous
>> integration. I'd like to have autobuilders for other platforms too.
>> After a few minutes searching, I see
hi Alin,
Thanks for the patch.
From my reading, it seems that you are attempting to add support in the kernel
datapath to not handle the UFID attribute gracefully, even though there’s no
support for it in the kernel datapath. It would be useful to add a comment in
the code to this effect that U
> On Feb 4, 2015, at 11:42 AM, Gurucharan Shetty wrote:
>
> On Fri, Jan 23, 2015 at 9:33 AM, Gurucharan Shetty wrote:
>> On Thu, Jan 22, 2015 at 9:19 PM, Ben Pfaff wrote:
>>> The travis autobuilder has been pretty awesome for GNU/Linux continuous
>>> integration. I'd like to have autobuilders
> I had a question regarding the machines that they provide. Have they been
> installed with the Visual studio packages for building the kernel datapath.
> We mostly need WDK 8.1.
These are the pre-installed software in the machine:
http://www.appveyor.com/docs/installed-software
Do you have wha
The tunnel module can get called by the handler threads right after
they are started, so we need to call ofproto_tunnel_init() before
opening the backer.
Late initialization caused a spurious ovs-vswitchd handler thread
crash on start-up due to the tunnel module fat_rwlock not being
initialized ye
> On Feb 4, 2015, at 12:27 PM, Gurucharan Shetty wrote:
>
>> I had a question regarding the machines that they provide. Have they been
>> installed with the Visual studio packages for building the kernel datapath.
>> We mostly need WDK 8.1.
> These are the pre-installed software in the machine:
> I’ll also voice my support for the request. It might help.
From other discussions, it looks like they are quite prompt in
installing new software.
> Do we build Linux datapath today in the public cloud (not appveyor)?
We build it. I don't think we let people download it from anywhere
after the b
On Wed, Feb 04, 2015 at 11:42:46AM -0800, Gurucharan Shetty wrote:
> On Fri, Jan 23, 2015 at 9:33 AM, Gurucharan Shetty wrote:
> > On Thu, Jan 22, 2015 at 9:19 PM, Ben Pfaff wrote:
> >> The travis autobuilder has been pretty awesome for GNU/Linux continuous
> >> integration. I'd like to have aut
On Wed, Feb 04, 2015 at 12:59:04PM -0800, Jarno Rajahalme wrote:
> The tunnel module can get called by the handler threads right after
> they are started, so we need to call ofproto_tunnel_init() before
> opening the backer.
>
> Late initialization caused a spurious ovs-vswitchd handler thread
> c
On Wednesday, February 04, 2015 10:54:59 AM Ben Pfaff wrote:
> On Wed, Feb 04, 2015 at 09:57:34AM -0800, Ben Pfaff wrote:
> > On Wed, Feb 04, 2015 at 11:07:05AM -0200, Flavio Leitner wrote:
> > > On Tuesday, February 03, 2015 04:07:24 PM Ben Pfaff wrote:
> > > > On Tue, Jan 20, 2015 at 01:20:56PM -
On 02/04/15 at 09:53am, Ben Pfaff wrote:
> On Wed, Feb 04, 2015 at 04:10:59PM +0100, Thomas Graf wrote:
> > Inspired by Ben Pfaff's email on 32 bit build environment, this adds a
> > 32bit build to the travis build matrix to catch alignment and padding
> > issues.
> >
> > The 32 bit build is only
On Tue, Feb 3, 2015 at 5:54 PM, Alex Wang wrote:
> For testing purpose, developers may want to change the NON_PMD_CORE_ID
> and use a different core for non-pmd threads. Since the netdev-dpdk
> module is hard-coded to assert the non-pmd threads using core 0, such
> change will cause abortion of O
On Tue, Feb 3, 2015 at 11:04 PM, Vasiliy Tolstov wrote:
>
> 2015-02-04 10:04 GMT+03:00 Vasiliy Tolstov :
>>
>> Does it possible to add to readme test results posted in mailing list
>> about vxlan and stt and do this tests also (on the same hardware) for gre,
>> listp, geneve?
>
>
> Or openvswitch
Joe and I have been experimenting with BPF and its application for OVS.
This patch shows our attempt to implement ovs actions using eBPF.
The kernel changes are against the 'net-next'. The corresponding
user space changes will be post next.
This patch set implements an BPF action, that has the sa
Add a new program type for openvswitch. Implements the BPF verifier
for the new type.
Signed-off-by: Andy Zhou
---
include/linux/bpf.h | 2 +-
include/uapi/linux/bpf.h | 1 +
include/uapi/linux/openvswitch.h | 29 +-
net/Makefile | 4 +-
ne
User space changes of BPF OVS action agains curret OVS master.
Andy Zhou (9):
hack: Do not compile datapath
odp: add a new ODP action: OVS_ACTION_ATTR_BPF_PROG
tests: add a OVS_ACTION_ATTR_BPF_PROG ation unit test case
autoconf: support -with-llc options
bpf: add the first BPF program.
BPF_PROG action allows an action to be implemented in eBPF language and
downloaded by the userspace at runtime.
Signed-off-by: Andy Zhou
---
net/openvswitch/actions.c | 30 ++
net/openvswitch/datapath.c | 6 ++-
net/openvswitch/flow_netlink.c | 92 ++
The OVS eBPF patch sets are developed against master 'net-next' tree,
which is currently targeting for kernel version 3.19.
The datapath in OVS mater does not currently support 3.19 kernel.
But we should not really using OVS datapath, The changes in the
follow patches are only changes in user spac
Add a new ODP action and implements the corresponding Netlink message
handling of this new attribute.
Signed-off-by: Andy Zhou
---
datapath/linux/compat/include/linux/openvswitch.h | 29 +++-
lib/dpif-netdev.c | 1 +
lib/dpif.c
Test parsing and formating of the newly added action.
Signed-off-by: Andy Zhou
---
tests/odp.at | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/odp.at b/tests/odp.at
index 8f96c6a..29a977f 100644
--- a/tests/odp.at
+++ b/tests/odp.at
@@ -282,6 +282,7 @@ tnl_pop(4)
tnl_push(tnl_port(4
Add a configuration option to allow specifing the LLVM backend module
for compiling BPF C source code into BPF instruction sets.
See INSTALL.BPF.md for usgae information.
Signed-off-by: Joe Stringer
Signed-off-by: Andy Zhou
---
INSTALL.BPF.md | 42 ++
Ma
This patch prevents wiping flows if the xen pool's controller is not the first
controller in the `get-manger` output. It also updates the quoting to be
to be consistant and follows PEP8 guidelines.
.../etc_xapi.d_plugins_openvswitch-cfg-update | 163 +++-
1 file changed, 88 ins
Added a BPF implementation of output action. The intention is to have
all OVS related BPF programs live under the 'bpf' folder.
Signed-off-by: Andy Zhou
---
Makefile.am | 1 +
bpf/automake.mk | 27 +++
bpf/bpf-shared.h | 12
bpf/ovs-acti
Added a eBPF program loader in ofproto-dpif layer. It only loades
the OVS programs.
Signed-off-by: Andy Zhou
---
ofproto/automake.mk| 2 +
ofproto/ofproto-dpif-bpf.c | 454 +
ofproto/ofproto-dpif-bpf.h | 42 +
vswitchd/automake.mk
Those files are basically imported from 'net-next: sample/bpf'
directory. This is a stop gap measure unil libbpf is upstreamed.
Signed-off-by: Andy Zhou
---
lib/automake.mk | 22 +++
lib/libbpf.c| 100 ++
lib/libbpf.h| 185 +++
With XenServer only 1 manager is configured in the pool, which may not
be the first manager returned from `get-manager` as it returns in
lexicographical order.
Signed-off-by: Jason Kölker
---
.../etc_xapi.d_plugins_openvswitch-cfg-update | 22 +++---
1 file changed, 11 inser
First cut in added datpath eBPF support detector. This feature has not
been fully developed. The stub implementation simply assumes the
datpath support eBPF.
Signed-off-by: Andy Zhou
Current interface only support 'yes' or 'no' detection. Should we
consider 'support level'?
---
ofproto/ofp
Signed-off-by: Jason Kölker
---
.../etc_xapi.d_plugins_openvswitch-cfg-update | 147 +++--
1 file changed, 80 insertions(+), 67 deletions(-)
diff --git a/xenserver/etc_xapi.d_plugins_openvswitch-cfg-update
b/xenserver/etc_xapi.d_plugins_openvswitch-cfg-update
index 2df838a.
This is a hack in xlate code to always generate both BPF output
and the original output action. Since the currnet BPF output 'action'
simply generate a kenrel log message about the output port number.
With this patch, Every time datapath output a packet, it also generate
log about the port number
Hey Daniele,
Do you still remember why you mentioned:
"/* We have to use 0 to allow non pmd threads to perform certain DPDK
* operations, like rte_eth_dev_configure(). */
"
in your commit: db73f716 (netdev-dpdk: Fix race condition with DPDK
mempools in non pmd threads)
This posted commit works d
On Wed, Feb 4, 2015 at 7:45 AM, Thomas Graf wrote:
> Upstream commit:
> openvswitch: Support VXLAN Group Policy extension
>
> Introduces support for the group policy extension to the VXLAN virtual
> port. The extension is disabled by default and only enabled if the user
> has provi
OVS userspace already probes the openvswitch kernel module for
OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module
implementation of masked set actions.
The existing set action sets many fields at once. When only a subset
of the IP header fields, for example, should be modified
Hey Alin,
Thanks for the patch.
Please find my comments inline.
I have not worked on this code for sometime, so may miss something here.
Can you please also let us know the unit testing that you did? Although change
is minor, but editing FLOW_KEY* related code may end up breaking some
function
Thanks for review, merged with master.
Jarno
On Feb 4, 2015, at 1:47 PM, Ben Pfaff wrote:
> On Wed, Feb 04, 2015 at 12:59:04PM -0800, Jarno Rajahalme wrote:
>> The tunnel module can get called by the handler threads right after
>> they are started, so we need to call ofproto_tunnel_init() bef
Hey Alex,
I remember that calling certain DPDK functions (that we use to
initialize devices) with '_lcore_id !=0' resulted in an error. If this
is not the case anymore with DPDK 1.7.1 (i.e. if you tested this patch
with NON_PMD_CORE_ID!=0 and it worked), then I have no objection.
I would test thi
On Wed, Feb 4, 2015 at 4:16 PM, Jarno Rajahalme wrote:
> OVS userspace already probes the openvswitch kernel module for
> OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module
> implementation of masked set actions.
>
> The existing set action sets many fields at once. When only
On Wed, Feb 4, 2015 at 4:16 PM, Jarno Rajahalme wrote:
> OVS userspace already probes the openvswitch kernel module for
> OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module
> implementation of masked set actions.
>
> The existing set action sets many fields at once. When only
With XenServer only 1 manager is configured in the pool, which may not
be the first manager returned from `get-manager` as it returns in
lexicographical order.
V2: Fixes vswitchCurrentControllers() to always return a list
Signed-off-by: Jason Kölker
---
.../etc_xapi.d_plugins_openvswitch-cfg-up
On 4 February 2015 at 16:31, Ankur Sharma wrote:
>
> @@ -103,7 +103,9 @@ const NL_POLICY nlFlowPolicy[] = {
> .maxLen = sizeof(struct ovs_flow_stats),
> .optional = TRUE},
> [OVS_FLOW_ATTR_TCP_FLAGS] = {NL_A_U8, .optional = TRUE},
>
On Fri, Jan 23, 2015 at 10:10 AM, Madhu Challa wrote:
> This commit adds support for Geneve flow mods via two nicira extensions.
> NXM_NX_TUN_METADATA for being able to match on tun_metadata nxms and
> NXAST_RAW_TUN_METADATA for tun_metadata actions.
This is great, thanks!
> The other side affec
59 matches
Mail list logo
