[ovs-dev] Re
Confirm your Donation of £2,000.000.00 Contact Kindly contact claims office via Email: nil-trot...@hotmail.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OFP14 set async config - dev query
On Mon, Feb 02, 2015 at 08:13:22PM -0800, Shashaankar Reddy wrote:
> I'm working on implementing OFP1.4 specific feature to set/get async
> configuration on a switch.
>
> From the code I understand that OFPTYPE_SET_ASYNC_CONFIG being referred to
> both nicira-xt and OFP13 messages:
> /* OFPRAW_NXT_SET_ASYNC_CONFIG.
> * OFPRAW_OFPT13_SET_ASYNC. */
> The set async config calls from controller gets handled at
> 'handle_openflow__(...)'
>
> Here are my questions:
> # Should I use same OFPTYPE_SET_ASYNC_CONFIG for set config message for
> OFP14, then based on ofpheader->version call another function to decode and
> apply mask settings ?
Yes.
> # Else should I create a new 'OFPTYPE_...' for OFP14, and have altogether a
> different path to make settings ?
No.
> # Also I believe 'enum ofconn_async_msg_type { ...' should be evolved
> with new OFP14 async message types ?
I don't think that OF1.4 introduces any new async message types. If it
does then they should be added there.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: > One question on STT IP, is it free to use STT in commercial products? > I believe Nicira has patents on this. Assuming that Nicira does, the patches are being offered by the patent holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-command-completion: Complete on file path by default.
On Mon, Feb 02, 2015 at 01:03:35PM -0800, Alex Wang wrote: > This commit makes the bash completion script complete on file > path when there is no completion available. The unit tests > are also adjusted accordingly. > > Signed-off-by: Alex Wang I feel like I just have to take your word on this one (if anyone wants to carefully review it, please speak up!). Acked-by: Ben Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] miniflow: Fix miniflow push of L4 port numbers.
On Mon, Feb 02, 2015 at 10:47:48PM +, Kevin Traynor wrote: > Replace a 64 bit copy of L4 src/dst ports that was also > including additional packet params (e.g. TCP Seq Num). This > was later resulting in all packets from the flow missing in > the EMC. > > Signed-off-by: Kevin Traynor > Reported-by: Ciara Loftus Thank you for finding this subtle issue! This bit of code is, in my opinion, full of landmines. We really need to come up with a less-risky approach. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] layer 3 ports and OVS_KEY_ATTR_PACKET_ETHERTYPE (was Re: [PATCH v8 5/5] datapath: add layer 3 support to ovs_packet_cmd_execute())
Lori, The refinements proposed by Thomas seem sensible to me. Please proceed as planned below. Regards, Jarno On Feb 2, 2015, at 10:15 PM, Lori Jakab wrote: > Sorry to insist, but can you guys (Jesse/Pravin/Jarno) please look at > this and give your opinion so Thomas and I know how to proceed? > > -Lori > > On 01/23/2015 02:45 PM, Lori Jakab wrote: >> On 1/20/15 12:52 PM, Thomas Morin wrote: >>> Hi Jarno, Lori, >>> >>> On 12/10/2014 02:45 AM, Jarno Rajahalme wrote: We should add a new metadata key field OVS_KEY_ATTR_PACKET_ETHERTYPE, that contains the ethertype of the associated packet attribute. While this would be strictly needed only for L3 packets, it would be cleaner to include it with all packets in packet misses. Then it could be used in flow setup and packet execution as well. Other packet type namespaces (like IP protocol) could be later supported defining new netlink attributes. A corresponding new field packet_ethertype needs to be added in struct pkt_metadata. This needs to be kept upto date in userspace code pushing and popping headers, so that the correct value gets passed to kernel execution. >>> >>> Having the tunneled payload type be passed between kernel and >>> userspace via OVS_KEY_ATTR_PACKET_ETHERTYPE is something needed for >>> MPLS/GRE too (see [1] below). >>> >>> With some hints from Jesse back in November, I've been working in the >>> past weeks to see how much needed to be adapted based on your patch to >>> add support for l3 GRE tunnel ports, and have this work for >>> MPLS-over-GRE payloads. I've not everything covered yet, but I have >>> the basic stuff working (with a kernel dataplane). >>> >>> Here is an outline of the things I did to support MPLS/GRE based on >>> the current l3 port patch (l3_v9), and that I think that these are >>> also relevant to simplify the code in the IP/non-MPLS case : >>> - kernel: adapt ovs_nla_put_flow to include >>> OVS_KEY_ATTR_PACKET_ETHERTYPE in the noethernet case (not done in the >>> current l3_v9 patch, in which the kernel datapath consume a value >>> given by userspace for a flow put or a command execute, but does not >>> provides this info on a flow miss) >>> - user: have odp_key_to_pkt_metadata determine md->packet_ethertype >>> based on OVS_KEY_ATTR_PACKET_ETHERTYPE, rather than base on the >>> presence of OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6) >>> - user: similarly for parse_ethertype, to determine the ethertype >>> (based on OVS_KEY_ATTR_PACKET_ETHERTYPE rather than base on the >>> presence of OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6) >>> - user: have miniflow_extract rely on md->packet_ethertype for layer3 >>> frames and do not use get_l3_eth_type anymore (which was guessing >>> ethertype based on the version field of the IP header) >>> - kernel: have ovs_key_from_nlattrs use OVS_KEY_ATTR_PACKET_ETHERTYPE, >>> if present, to determine the ethertype >>> >>> Comments ? >> >> I will defer judgement to Jesse, Pravin, and Jarno. I don't mind >> changing the kernel/userspace API to this direction, it looks cleaner to >> me, although I don't know if it has significant performance or >> compatibility implications. >> >>> >>> >>> Lori, I have the above working on my tree and will share code if we >>> agree that this is the right direction. >> >> If there is consensus to use this approach I will pull your work into my >> tree and submit it along with my existing patches. Looking forward to >> feedback from the guys who reviewed my patches so far. >> >> -Lori >> >>> >>> Best, >>> >>> -Thomas >>> >>> [1] because MPLS can be used with two ethertypes (0x8847,0x8848) and a >>> different semantic can be given to an MPLS label depending on the >>> ethtype. This contrasts with IP, for which the ethertype can be >>> guessed/derived from the presence of OVS_KEY_ATTR_IPV(4|6) or the >>> version field of the IP header. >>> ___ >>> dev mailing list >>> dev@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev >> >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 01/13] datapath: Account for "rename vlan_tx_* helpers since "tx" is misleading there"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Upstream commit:
> net: rename vlan_tx_* helpers since "tx" is misleading there
>
> The same macros are used for rx as well. So rename it.
>
> Signed-off-by: Jiri Pirko
> Signed-off-by: David S. Miller
>
> Upstream: df8a39d ("net: rename vlan_tx_* helpers since "tx" is misleading
> there")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 02/13] datapath: Account for now exposed VXLAN definitions
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> This brings the compat version of vxlan_udp_encap_recv() and
> vxlan_xmit_skb() in line with upstream commit:
>
> commit 3bf3947526c1053ddf2523f261395d682718f56c
> Author: Tom Herbert
> Date: Thu Jan 8 12:31:18 2015 -0800
>
> vxlan: Improve support for header flags
>
> This patch cleans up the header flags of VXLAN in anticipation of
> defining some new ones:
>
> - Move header related definitions from vxlan.c to vxlan.h
> - Change VXLAN_FLAGS to be VXLAN_HF_VNI (only currently defined flag)
> - Move check for unknown flags to after we find vxlan_sock, this
> assumes that some flags may be processed based on tunnel
> configuration
> - Add a comment about why the stack treating unknown set flags as an
> error instead of ignoring them
>
> Signed-off-by: Tom Herbert
> Signed-off-by: David S. Miller
>
> Upstream: 3bf394 ("vxlan: Improve support for header flags")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 03/13] datapath: Account for "vxlan: Group Policy extension"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Upstream commit:
> vxlan: Group Policy extension
>
> Implements supports for the Group Policy VXLAN extension [0] to provide
> a lightweight and simple security label mechanism across network peers
> based on VXLAN. The security context and associated metadata is mapped
> to/from skb->mark. This allows further mapping to a SELinux context
> using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> tc, etc.
>
> The group membership is defined by the lower 16 bits of skb->mark, the
> upper 16 bits are used for flags.
>
> SELinux allows to manage label to secure local resources. However,
> distributed applications require ACLs to implemented across hosts. This
> is typically achieved by matching on L2-L4 fields to identify the
> original sending host and process on the receiver. On top of that,
> netlabel and specifically CIPSO [1] allow to map security contexts to
> universal labels. However, netlabel and CIPSO are relatively complex.
> This patch provides a lightweight alternative for overlay network
> environments with a trusted underlay. No additional control protocol
> is required.
>
>Host 1: Host 2:
>
> Group AGroup BGroup B Group A
> +-+ +-++---+ +-+
> | lxc | | SELinux CTX || httpd | | VM |
> +--+--+ +--+--++---+---+ +--+--+
> \---+---/ \+---/
> | |
> +---+---+ +---+---+
> | vxlan | | vxlan |
> +---+---+ +---+---+
> +--+
>
> Backwards compatibility:
> A VXLAN-GBP socket can receive standard VXLAN frames and will assign
> the default group 0x to such frames. A Linux VXLAN socket will
> drop VXLAN-GBP frames. The extension is therefore disabled by default
> and needs to be specifically enabled:
>
>ip link add [...] type vxlan [...] gbp
>
> In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
> must run on a separate port number.
>
> Examples:
> iptables:
> host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark
> 0x200
> host2# iptables -I INPUT -m mark --mark 0x200 -j DROP
>
> OVS:
> # ovs-ofctl add-flow br0
> 'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
> # ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'
>
> [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
> [1] http://lwn.net/Articles/204905/
>
> Signed-off-by: Thomas Graf
> Signed-off-by: David S. Miller
>
> Upstream: 351149 ("vxlan: Group Policy extension")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 04/13] datapath: Account for "vxlan: add x-netns support"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Upstream commit:
> vxlan: add x-netns support
>
> This patch allows to switch the netns when packet is encapsulated or
> decapsulated.
> The vxlan socket is openned into the i/o netns, ie into the netns where
> encapsulated packets are received. The socket lookup is done into this
> netns to
> find the corresponding vxlan tunnel. After decapsulation, the packet is
> injecting into the corresponding interface which may stand to another
> netns.
>
> When one of the two netns is removed, the tunnel is destroyed.
>
> Configuration example:
> ip netns add netns1
> ip netns exec netns1 ip link set lo up
> ip link add vxlan10 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0
> ip link set vxlan10 netns netns1
> ip netns exec netns1 ip addr add 192.168.0.249/24 broadcast 192.168.0.255
> dev vxlan10
> ip netns exec netns1 ip link set vxlan10 up
>
> Signed-off-by: Nicolas Dichtel
> Signed-off-by: David S. Miller
>
> Upstream: f01ec1c017de ("vxlan: add x-netns support")
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 05/13] datapath: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Backport of upstream commit:
>
> openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
>
> Also factors out Geneve validation code into a new separate function
> validate_and_copy_geneve_opts().
>
> A subsequent patch will introduce VXLAN options. Rename the existing
> GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
> tunnel metadata options.
>
> Signed-off-by: Thomas Graf
> Signed-off-by: David S. Miller
>
> Upstream: d91641d ("openvswitch: Rename GENEVE_TUN_OPTS() to
> TUN_METADATA_OPTS()")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 06/13] datapath: Allow for any level of nesting in flow attributes
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Upstream commit:
> openvswitch: Allow for any level of nesting in flow attributes
>
> nlattr_set() is currently hardcoded to two levels of nesting. This change
> introduces struct ovs_len_tbl to define minimal length requirements plus
> next level nesting tables to traverse the key attributes to arbitrary
> depth.
>
> Signed-off-by: Thomas Graf
> Signed-off-by: David S. Miller
>
> Upstream: 81bfe3 ("openvswitch: Allow for any level of nesting in flow
> attributes")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On Fri, Jan 30, 2015 at 6:36 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 provided the respective configuration.
>
> ovs-vsctl add-port br0 vxlan0 -- \
> set Interface vxlan0 type=vxlan options:exts=gbp
>
> The configuration interface to enable the extension is based on a new
> attribute OVS_VXLAN_EXT_GBP nested inside OVS_TUNNEL_ATTR_EXTENSION
> which can carry additional extensions as needed in the future.
>
> The group policy metadata is stored as binary blob (struct ovs_vxlan_opts)
> internally just like Geneve options but transported as nested Netlink
> attributes to user space.
>
> Renames the existing TUNNEL_OPTIONS_PRESENT to TUNNEL_GENEVE_OPT with the
> binary value kept intact, a new flag TUNNEL_VXLAN_OPT is introduced.
>
> The attributes OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS and existing
> OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS are implemented mutually exclusive.
>
> Signed-off-by: Thomas Graf
> Signed-off-by: David S. Miller
>
> Upstream: 1dd144 ("openvswitch: Support VXLAN Group Policy extension")
> Signed-off-by: Thomas Graf
> ---
> datapath/Modules.mk | 3 +-
> datapath/flow_netlink.c | 114
> +++---
> datapath/linux/compat/include/linux/openvswitch.h | 10 ++
> datapath/linux/compat/include/net/ip_tunnels.h| 16 ++-
> datapath/vport-geneve.c | 6 +-
> datapath/vport-vxlan.c| 82 +++-
> datapath/vport-vxlan.h| 11 +++
> 7 files changed, 223 insertions(+), 19 deletions(-)
> create mode 100644 datapath/vport-vxlan.h
>
> --- a/datapath/vport-vxlan.c
> +++ b/datapath/vport-vxlan.c
> @@ -41,6 +41,7 @@
>
> #include "datapath.h"
> #include "vport.h"
> +#include "vport-vxlan.h"
>
> /**
> * struct vxlan_port - Keeps track of open UDP ports
> @@ -50,6 +51,7 @@
> struct vxlan_port {
> struct vxlan_sock *vs;
> char name[IFNAMSIZ];
> + u32 exts; /* VXLAN_F_* in */
> };
>
> static inline struct vxlan_port *vxlan_vport(const struct vport *vport)
> @@ -61,16 +63,26 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct
> sk_buff *skb,
> struct vxlan_metadata *md)
> {
> struct ovs_tunnel_info tun_info;
> + struct vxlan_port *vxlan_port;
> struct vport *vport = vs->data;
> struct iphdr *iph;
> + struct ovs_vxlan_opts opts = {
> + .gbp = md->gbp,
> + };
> __be64 key;
> + __be16 flags;
> +
> + flags = TUNNEL_KEY;
> + vxlan_port = vxlan_vport(vport);
> + if (vxlan_port->exts & VXLAN_F_GBP)
> + flags |= TUNNEL_VXLAN_OPT;
>
This does not allow GBP and non-GBP tunnel share vxlan port, since OVS
we have single vport shared between all vxlan end-points for given UDP
port.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 08/13] datapath: Account for "vxlan: Eliminate dependency on UDP socket in transmit path"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> 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,
> need the vxlan_dev flags. This patch eliminate references
> to the socket in the transmit path, and changes VXLAN_F_UNSHAREABLE
> to be VXLAN_F_RCV_FLAGS. This mask is used to store the flags
> applicable to receive (GBP, CSUM6_RX, and REMCSUM_RX) in the
> vxlan_sock flags.
>
> Signed-off-by: Tom Herbert
> Signed-off-by: David S. Miller
>
> Upstream: af33c1adae1e ("vxlan: Eliminate dependency on UDP socket in
> transmit path")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [connectibity_seq 3/4] connectivity: Coverage count the connectivity_seq changes.
This commit uses coverage counter to monitor the changing rate of
connectivity_seq.
Signed-off-by: Alex Wang
---
lib/connectivity.c |4
1 file changed, 4 insertions(+)
diff --git a/lib/connectivity.c b/lib/connectivity.c
index 639224e..d8defbc 100644
--- a/lib/connectivity.c
+++ b/lib/connectivity.c
@@ -18,11 +18,14 @@
#include "backtrace.h"
#include "connectivity.h"
+#include "coverage.h"
#include "ovs-atomic.h"
#include "ovs-thread.h"
#include "seq.h"
#include "unixctl.h"
+COVERAGE_DEFINE(conn_seq_change);
+
/* Provides a global seq for connectivity changes.
*
* Connectivity monitoring modules should use the public functions in this
@@ -92,6 +95,7 @@ connectivity_seq_change(void)
connectivity_seq_init();
+COVERAGE_INC(conn_seq_change);
atomic_read(&log_source, &log_enabled);
if (log_enabled) {
log_call_stack();
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [connectibity_seq 1/4] connectivity: Add wrappers to connectivity related operations.
This commit refines the connectivity module by defining wrappers
for each related operation.
Signed-off-by: Alex Wang
---
lib/bfd.c |2 +-
lib/cfm.c |2 +-
lib/connectivity.c| 45 ++---
lib/connectivity.h|4 +++-
lib/lacp.c|4 ++--
lib/netdev-provider.h | 11 +--
lib/rstp-state-machines.c |4 ++--
lib/rstp.c|2 +-
lib/stp.c |6 +++---
ofproto/bond.c|6 +++---
ofproto/ofproto-dpif.c|2 +-
ofproto/ofproto.c |4 ++--
vswitchd/bridge.c |6 +++---
13 files changed, 61 insertions(+), 37 deletions(-)
diff --git a/lib/bfd.c b/lib/bfd.c
index 3db1d57..86378d4 100644
--- a/lib/bfd.c
+++ b/lib/bfd.c
@@ -1198,7 +1198,7 @@ bfd_decay_update(struct bfd * bfd) OVS_REQUIRES(mutex)
static void
bfd_status_changed(struct bfd *bfd) OVS_REQUIRES(mutex)
{
-seq_change(connectivity_seq_get());
+connectivity_seq_change();
bfd->status_changed = true;
}
diff --git a/lib/cfm.c b/lib/cfm.c
index 23c1c6f..fa0503c 100644
--- a/lib/cfm.c
+++ b/lib/cfm.c
@@ -338,7 +338,7 @@ cfm_init(void)
static void
cfm_status_changed(struct cfm *cfm) OVS_REQUIRES(mutex)
{
-seq_change(connectivity_seq_get());
+connectivity_seq_change();
cfm->status_changed = true;
}
diff --git a/lib/connectivity.c b/lib/connectivity.c
index c80b5f1..59f8a39 100644
--- a/lib/connectivity.c
+++ b/lib/connectivity.c
@@ -15,22 +15,21 @@
*/
#include
+
#include "connectivity.h"
#include "ovs-thread.h"
#include "seq.h"
-static struct seq *connectivity_seq;
-
/* Provides a global seq for connectivity changes.
*
- * Connectivity monitoring modules should call seq_change() on the returned
- * object whenever the status of a port changes, whether the cause is local or
- * remote.
- *
- * Clients can seq_wait() on this object for changes to netdev flags, features,
- * ethernet addresses, carrier changes, and bfd/cfm/lacp/stp status. */
-struct seq *
-connectivity_seq_get(void)
+ * Connectivity monitoring modules should use the public functions in this
+ * module to report, check or wait on link/port status change.
+ * */
+static struct seq *connectivity_seq;
+
+/* Runs only once to initialize 'connectivity_seq'. */
+static void
+connectivity_seq_init(void)
{
static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
@@ -38,6 +37,30 @@ connectivity_seq_get(void)
connectivity_seq = seq_create();
ovsthread_once_done(&once);
}
+}
+
+/* Reads and returns the current 'connectivity_seq' value. */
+uint64_t
+connectivity_seq_read(void)
+{
+connectivity_seq_init();
-return connectivity_seq;
+return seq_read(connectivity_seq);
+}
+
+/* Changes the 'connectivity_seq'. */
+void
+connectivity_seq_change(void)
+{
+connectivity_seq_init();
+seq_change(connectivity_seq);
+}
+
+/* Wakes the caller up when 'connectivity_seq''s sequence number
+ * changes from 'value'. */
+void
+connectivity_seq_wait(uint64_t value)
+{
+connectivity_seq_init();
+seq_wait(connectivity_seq, value);
}
diff --git a/lib/connectivity.h b/lib/connectivity.h
index 123e886..f00f960 100644
--- a/lib/connectivity.h
+++ b/lib/connectivity.h
@@ -20,6 +20,8 @@
#include
/* For tracking connectivity changes globally. */
-struct seq *connectivity_seq_get(void);
+uint64_t connectivity_seq_read(void);
+void connectivity_seq_change(void);
+void connectivity_seq_wait(uint64_t value);
#endif /* connectivity.h */
diff --git a/lib/lacp.c b/lib/lacp.c
index 6f52652..219355a 100644
--- a/lib/lacp.c
+++ b/lib/lacp.c
@@ -528,7 +528,7 @@ lacp_run(struct lacp *lacp, lacp_send_pdu *send_pdu)
OVS_EXCLUDED(mutex)
slave_set_defaulted(slave);
}
if (slave->status != old_status) {
-seq_change(connectivity_seq_get());
+connectivity_seq_change();
}
}
}
@@ -561,7 +561,7 @@ lacp_run(struct lacp *lacp, lacp_send_pdu *send_pdu)
OVS_EXCLUDED(mutex)
: LACP_SLOW_TIME_TX);
timer_set_duration(&slave->tx, duration);
-seq_change(connectivity_seq_get());
+connectivity_seq_change();
}
}
lacp_unlock();
diff --git a/lib/netdev-provider.h b/lib/netdev-provider.h
index 3fdc732..6c94c7f 100644
--- a/lib/netdev-provider.h
+++ b/lib/netdev-provider.h
@@ -64,7 +64,7 @@ static void
netdev_change_seq_changed(const struct netdev *netdev_)
{
struct netdev *netdev = CONST_CAST(struct netdev *, netdev_);
-seq_change(connectivity_seq_get());
+connectivity_seq_change();
netdev->change_seq++;
if (!netdev->change_seq) {
netdev->change_seq++;
@@ -187,11 +187,10 @@ struct netdev *netdev_rxq_get_netdev(const struct
netdev_rxq *);
* ==
*
* Minimally, implementations are required to report
Re: [ovs-dev] [PATCH 09/13] datapath: Account for "genetlink: pass only network namespace to genl_has_listeners()"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> Upstream commit:
> genetlink: pass only network namespace to genl_has_listeners()
>
> There's no point to force the caller to know about the internal
> genl_sock to use inside struct net, just have them pass the network
> namespace. This doesn't really change code generation since it's
> an inline, but makes the caller less magic - there's never any
> reason to pass another socket.
>
> Signed-off-by: Johannes Berg
> Signed-off-by: David S. Miller
>
> Upstream: f8403a2 ("genetlink: pass only network namespace to
> genl_has_listeners()")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 10/13] datapath: Account for "netlink: make nlmsg_end() and genlmsg_end() void"
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote:
> genlmsg_end() no longer returns an error value. Not a problem as it
> never returned an error code anyway.
>
> Upstream: 053c09 ("netlink: make nlmsg_end() and genlmsg_end() void")
> Signed-off-by: Thomas Graf
Acked-by: Pravin B Shelar
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [connectibity_seq 4/4] tunnel: Coverage count the 'tnl_port' reconfiguration.
This commit uses coverage counter to monitor the rate of
'struct tnl_port' reconfiguration.
Signed-off-by: Alex Wang
---
ofproto/tunnel.c |4
1 file changed, 4 insertions(+)
diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c
index d079a24..722a5cf 100644
--- a/ofproto/tunnel.c
+++ b/ofproto/tunnel.c
@@ -19,6 +19,7 @@
#include "byte-order.h"
#include "connectivity.h"
+#include "coverage.h"
#include "csum.h"
#include "dpif.h"
#include "dynamic-string.h"
@@ -42,6 +43,8 @@
VLOG_DEFINE_THIS_MODULE(tunnel);
+COVERAGE_DEFINE(tnl_reconfig);
+
/* skb mark used for IPsec tunnel packets */
#define IPSEC_MARK 1
@@ -234,6 +237,7 @@ tnl_port_reconfigure(const struct ofport_dpif *ofport,
|| tnl_port->match.odp_port != odp_port
|| tnl_port->change_seq !=
netdev_get_change_seq(tnl_port->netdev)) {
VLOG_DBG("reconfiguring %s", tnl_port_get_name(tnl_port));
+COVERAGE_INC(tnl_reconfig);
tnl_port_del__(ofport);
tnl_port_add__(ofport, netdev, odp_port, true, native_tnl, name);
changed = true;
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 11/13] datapath: Allow building against 3.19.x
On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote: > 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 versions > against which the > |2.0.x | 2.6.32 to 3.10 > |2.1.x | 2.6.32 to 3.11 > |2.3.x | 2.6.32 to 3.14 > +|2.4.x | 2.6.32 to 3.19 > > Open vSwitch userspace should also work with the Linux kernel module > built into Linux 3.3 and later. > diff --git a/NEWS b/NEWS > index 0a54820..9e39744 100644 > --- a/NEWS > +++ b/NEWS > @@ -57,7 +57,7 @@ Post-v2.3.0 > - Added support for DPDK Tunneling. VXLAN and GRE are supported protocols. > This is generic tunneling mechanism for userspace datapath. > - Support for multicast snooping (IGMPv1 and IGMPv2) > - - Support for Linux kernels up to 3.18.x > + - Support for Linux kernels up to 3.19.x > - The documentation now use the term 'destination' to mean one of syslog, > console or file for vlog logging instead of the previously used term > 'facility'. > diff --git a/acinclude.m4 b/acinclude.m4 > index cb3e148..c2f45ce 100644 > --- a/acinclude.m4 > +++ b/acinclude.m4 > @@ -134,10 +134,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [ > AC_MSG_RESULT([$kversion]) > > if test "$version" -ge 3; then > - if test "$version" = 3 && test "$patchlevel" -le 18; then > + if test "$version" = 3 && test "$patchlevel" -le 19; then >: # Linux 3.x > else > - AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version > newer than 3.18.x is not supported (please refer to the FAQ for advice)]) > + AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version > newer than 3.19.x is not supported (please refer to the FAQ for advice)]) > fi > else > if test "$version" -le 1 || test "$patchlevel" -le 5 || test > "$sublevel" -le 31; then > -- 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_vxlan_sock_add (err 0) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [connectibity_seq 2/4] connectivity: Log the call stack of connectivity_seq_change().
This commit allows users to log the call stack of
connectivity_seq_change().
Signed-off-by: Alex Wang
---
lib/connectivity.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/lib/connectivity.c b/lib/connectivity.c
index 59f8a39..639224e 100644
--- a/lib/connectivity.c
+++ b/lib/connectivity.c
@@ -16,9 +16,12 @@
#include
+#include "backtrace.h"
#include "connectivity.h"
+#include "ovs-atomic.h"
#include "ovs-thread.h"
#include "seq.h"
+#include "unixctl.h"
/* Provides a global seq for connectivity changes.
*
@@ -26,7 +29,28 @@
* module to report, check or wait on link/port status change.
* */
static struct seq *connectivity_seq;
+static atomic_bool log_source = ATOMIC_VAR_INIT(false);
+static void
+connectivity_unixctl_enable_log_source(struct unixctl_conn *conn,
+ int argc OVS_UNUSED,
+ const char *argv[] OVS_UNUSED,
+ void *aux OVS_UNUSED)
+{
+atomic_store(&log_source, true);
+unixctl_command_reply(conn, "log source enabled");
+}
+
+static void
+connectivity_unixctl_disable_log_source(struct unixctl_conn *conn,
+int argc OVS_UNUSED,
+const char *argv[] OVS_UNUSED,
+void *aux OVS_UNUSED)
+{
+atomic_store(&log_source, false);
+unixctl_command_reply(conn, "log source disabled");
+}
+
/* Runs only once to initialize 'connectivity_seq'. */
static void
connectivity_seq_init(void)
@@ -35,9 +59,21 @@ connectivity_seq_init(void)
if (ovsthread_once_start(&once)) {
connectivity_seq = seq_create();
+
+unixctl_command_register("connectivity/enable-log-source", "", 0, 0,
+ connectivity_unixctl_enable_log_source, NULL);
+unixctl_command_register("connectivity/disable-log-source", "", 0, 0,
+ connectivity_unixctl_disable_log_source,
NULL);
ovsthread_once_done(&once);
}
}
+
+/* Logs the calling stack. */
+static void
+log_call_stack(void)
+{
+log_backtrace_msg("connectivity_seq");
+}
/* Reads and returns the current 'connectivity_seq' value. */
uint64_t
@@ -52,7 +88,14 @@ connectivity_seq_read(void)
void
connectivity_seq_change(void)
{
+bool log_enabled;
+
connectivity_seq_init();
+
+atomic_read(&log_source, &log_enabled);
+if (log_enabled) {
+log_call_stack();
+}
seq_change(connectivity_seq);
}
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
On Mon, Feb 02, 2015 at 01:34:07PM -0800, Pravin Shelar wrote: > On Mon, Feb 2, 2015 at 11:20 AM, John W. Linville > wrote: > > On Mon, Feb 02, 2015 at 10:55:25AM -0800, Pravin Shelar wrote: > >> STT patches were posted on netdev mailing list, But it was rejected. > >> As policy datapath patches must be accepted first in upstream kernel > >> before ported to OVS repo. But considering STT is well known protocol, > >> it is used in production and it can be useful for community, we can > >> make exception for STT and maintain it in OVS repo. > >> If anyone has objection to merging STT support let us know. > > > > What is preventing the upstream merge? > > > > Here is link to netdev patch, you can have a look at the discussion. > > http://marc.info/?l=linux-netdev&m=142257416618642&w=2 Thanks for doing that research for me! :-) You don't see any way to work with Dave M. around his objections? Violating an "upstream first" policy seems like you are making an "end run" in hopes of eventually coming back to Dave M. with an argument like "but people have been using this already". I could be wrong, but that probably won't make Dave any more happy about merging the patchset in the future... john -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
On Tue, Feb 3, 2015 at 12:19 PM, John W. Linville wrote: > Thanks for doing that research for me! :-) You don't see any way to > work with Dave M. around his objections? > It seems to be a philosophical objection, which is likely intractable. > Violating an "upstream first" policy seems like you are making an "end > run" in hopes of eventually coming back to Dave M. with an argument > like "but people have been using this already". People are already using it, so some sufficiency of deployment probably isn't going to tip the scales.. :-) Fundamentally this comes down to a disagreement over whether users should be allowed to choose to use a protocol which performs poorly or not at all in the face of certain topologies. Personally I believe that users ought to be given that choice to make for themselves (and this is really already true at varying levels for all of the supported tunneling protocols, due to device support, firewalls, middleboxes, etc.), but I don't think you're going to find community consensus on this. As an aside, the assertion that routers absolutely depend on tools like RED is patently ridiculous. It is possible that naive *networks* depend on these tools, but the router couldn't care less. TCP back-off and shaping tools that depend on knowledge of the state machine are effectively "cooperative" bandwidth management tools that hope - but cannot guarantee - that they know how the sender will react and you should *never* rely on them contributing significantly to traffic engineering on your network. -- Nick ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ofproto-dpif: Revalidate when sFlow probability changes.
Thanks! Applied to master and branch-2.[310].
On Mon, Feb 02, 2015 at 12:41:48PM -0800, Jarno Rajahalme wrote:
> LGTM,
>
> Acked-by: Jarno Rajahalme
>
> On Jan 30, 2015, at 1:36 PM, Ben Pfaff wrote:
>
> > Until now, when the sFlow selection probability changed, OVS failed to
> > immediately revalidate the flow table, delaying the new probability taking
> > effect. This commit fixes the problem.
> >
> > Reported-by: K 華
> > Signed-off-by: Ben Pfaff
> > ---
> > AUTHORS| 1 +
> > ofproto/ofproto-dpif.c | 5 -
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/AUTHORS b/AUTHORS
> > index 366ad9b..0ac1a74 100644
> > --- a/AUTHORS
> > +++ b/AUTHORS
> > @@ -259,6 +259,7 @@ Joan Cirer j...@ev0.net
> > John Darrington j...@darrington.wattle.id.au
> > John Galgay j...@galgay.net
> > John Hurley john.hur...@netronome.com
> > +K 華k940...@hotmail.com
> > Kevin Mancuso kevin.manc...@rackspace.com
> > Kiran Shanbhog ki...@vmware.com
> > Kirill Kabardin
> > diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> > index 1b4ad12..b909fd9 100644
> > --- a/ofproto/ofproto-dpif.c
> > +++ b/ofproto/ofproto-dpif.c
> > @@ -1894,6 +1894,7 @@ set_sflow(struct ofproto *ofproto_,
> > struct dpif_sflow *ds = ofproto->sflow;
> >
> > if (sflow_options) {
> > +uint32_t old_probability = ds ? dpif_sflow_get_probability(ds) : 0;
> > if (!ds) {
> > struct ofport_dpif *ofport;
> >
> > @@ -1901,9 +1902,11 @@ set_sflow(struct ofproto *ofproto_,
> > HMAP_FOR_EACH (ofport, up.hmap_node, &ofproto->up.ports) {
> > dpif_sflow_add_port(ds, &ofport->up, ofport->odp_port);
> > }
> > -ofproto->backer->need_revalidate = REV_RECONFIGURE;
> > }
> > dpif_sflow_set_options(ds, sflow_options);
> > +if (dpif_sflow_get_probability(ds) != old_probability) {
> > +ofproto->backer->need_revalidate = REV_RECONFIGURE;
> > +}
> > } else {
> > if (ds) {
> > dpif_sflow_unref(ds);
> > --
> > 2.1.3
> >
> > ___
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] datapath-windows: accommodate to UFID changes
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.
Signed-off-by: Alin Gabriel Serdean
---
datapath-windows/ovsext/Flow.c | 26 +++---
datapath-windows/ovsext/Flow.h | 6 ++
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index d3de8cc..b849666 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -95,7 +95,7 @@ static NTSTATUS OvsDoDumpFlows(OvsFlowDumpInput *dumpInput,
/* For Parsing attributes in FLOW_* commands */
const NL_POLICY nlFlowPolicy[] = {
-[OVS_FLOW_ATTR_KEY] = {.type = NL_A_NESTED, .optional = FALSE},
+[OVS_FLOW_ATTR_KEY] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_MASK] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_ACTIONS] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_STATS] = {.type = NL_A_UNSPEC,
@@ -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},
-[OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE}
+[OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE},
+[OVS_FLOW_ATTR_UFID] = { .type = NL_A_UNSPEC, .optional = TRUE,
+ .minLen = sizeof(OvsU128) }
};
/* For Parsing nested OVS_FLOW_ATTR_KEY attributes.
@@ -308,6 +310,11 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
goto done;
}
+if (nlAttrs[OVS_FLOW_ATTR_KEY] == NULL) {
+nlError = NL_ERROR_INVAL;
+goto done;
+}
+
if ((rc = _MapNlToFlowPut(msgIn, nlAttrs[OVS_FLOW_ATTR_KEY],
nlAttrs[OVS_FLOW_ATTR_ACTIONS], nlAttrs[OVS_FLOW_ATTR_CLEAR],
&mappedFlow))
@@ -420,7 +427,7 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
PNL_MSG_HDR nlMsgOutHdr = NULL;
UINT32 attrOffset = NLMSG_HDRLEN + GENL_HDRLEN + OVS_HDRLEN;
PNL_ATTR nlAttrs[__OVS_FLOW_ATTR_MAX];
-
+NL_ERROR nlError = NL_ERROR_SUCCESS;
OvsFlowGetInput getInput;
OvsFlowGetOutput getOutput;
NL_BUFFER nlBuf;
@@ -455,6 +462,11 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
goto done;
}
+if (nlAttrs[OVS_FLOW_ATTR_KEY] == NULL) {
+nlError = NL_ERROR_INVAL;
+goto done;
+}
+
keyAttrOffset = (UINT32)((PCHAR) nlAttrs[OVS_FLOW_ATTR_KEY] -
(PCHAR)nlMsgHdr);
@@ -532,6 +544,14 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
*replyLen += NlMsgSize(nlMsgOutHdr);
done:
+if (nlError != NL_ERROR_SUCCESS) {
+POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
+usrParamsCtx->outputBuffer;
+NlBuildErrorMsg(msgIn, msgError, nlError);
+*replyLen = msgError->nlMsg.nlmsgLen;
+rc = STATUS_SUCCESS;
+}
+
return rc;
}
diff --git a/datapath-windows/ovsext/Flow.h b/datapath-windows/ovsext/Flow.h
index e817bcf..02a72de 100644
--- a/datapath-windows/ovsext/Flow.h
+++ b/datapath-windows/ovsext/Flow.h
@@ -37,6 +37,12 @@ typedef struct _OvsFlow {
NL_ATTR actions[1];
} OvsFlow;
+typedef union _OvsU128{
+uint32_t u32[4];
+struct {
+uint64_t lo, hi;
+} u64;
+} OvsU128;
typedef struct _OvsLayers {
UINT32 l3Ofs; // IPv4, IPv6, ARP, or other L3 header.
--
1.9.5.msysgit.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
On Tue, Feb 3, 2015 at 10:19 AM, John W. Linville wrote: > On Mon, Feb 02, 2015 at 01:34:07PM -0800, Pravin Shelar wrote: >> On Mon, Feb 2, 2015 at 11:20 AM, John W. Linville >> wrote: >> > On Mon, Feb 02, 2015 at 10:55:25AM -0800, Pravin Shelar wrote: >> >> STT patches were posted on netdev mailing list, But it was rejected. >> >> As policy datapath patches must be accepted first in upstream kernel >> >> before ported to OVS repo. But considering STT is well known protocol, >> >> it is used in production and it can be useful for community, we can >> >> make exception for STT and maintain it in OVS repo. >> >> If anyone has objection to merging STT support let us know. >> > >> > What is preventing the upstream merge? >> > >> >> Here is link to netdev patch, you can have a look at the discussion. >> >> http://marc.info/?l=linux-netdev&m=142257416618642&w=2 > > Thanks for doing that research for me! :-) You don't see any way to > work with Dave M. around his objections? > > Violating an "upstream first" policy seems like you are making an "end > run" in hopes of eventually coming back to Dave M. with an argument > like "but people have been using this already". I could be wrong, > but that probably won't make Dave any more happy about merging the > patchset in the future... > I do not have any plans of pushing STT to upstream kernel. I do not think increased STT usage will help us getting STT upstream in future. STT is useful tunneling protocol regardless of whether it is upstream or not and that is motivation of merging it to OVS repo. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath-windows: accommodate to UFID changes
Alin, looks good only minor thing :
+rc = STATUS_SUCCESS
Is redundant
Thanks,
Eitan
Acked-by: Eitan Eliahu
-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Alin Serdean
Sent: Tuesday, February 03, 2015 11:25 AM
To: dev@openvswitch.org
Subject: [ovs-dev] [PATCH] datapath-windows: accommodate to UFID changes
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.
Signed-off-by: Alin Gabriel Serdean
---
datapath-windows/ovsext/Flow.c | 26 +++---
datapath-windows/ovsext/Flow.h | 6 ++
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index d3de8cc..b849666 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -95,7 +95,7 @@ static NTSTATUS OvsDoDumpFlows(OvsFlowDumpInput *dumpInput,
/* For Parsing attributes in FLOW_* commands */ const NL_POLICY
nlFlowPolicy[] = {
-[OVS_FLOW_ATTR_KEY] = {.type = NL_A_NESTED, .optional = FALSE},
+[OVS_FLOW_ATTR_KEY] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_MASK] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_ACTIONS] = {.type = NL_A_NESTED, .optional = TRUE},
[OVS_FLOW_ATTR_STATS] = {.type = NL_A_UNSPEC, @@ -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},
-[OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE}
+[OVS_FLOW_ATTR_USED] = {NL_A_U64, .optional = TRUE},
+[OVS_FLOW_ATTR_UFID] = { .type = NL_A_UNSPEC, .optional = TRUE,
+ .minLen = sizeof(OvsU128) }
};
/* For Parsing nested OVS_FLOW_ATTR_KEY attributes.
@@ -308,6 +310,11 @@ OvsFlowNlCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
goto done;
}
+if (nlAttrs[OVS_FLOW_ATTR_KEY] == NULL) {
+nlError = NL_ERROR_INVAL;
+goto done;
+}
+
if ((rc = _MapNlToFlowPut(msgIn, nlAttrs[OVS_FLOW_ATTR_KEY],
nlAttrs[OVS_FLOW_ATTR_ACTIONS], nlAttrs[OVS_FLOW_ATTR_CLEAR],
&mappedFlow))
@@ -420,7 +427,7 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
PNL_MSG_HDR nlMsgOutHdr = NULL;
UINT32 attrOffset = NLMSG_HDRLEN + GENL_HDRLEN + OVS_HDRLEN;
PNL_ATTR nlAttrs[__OVS_FLOW_ATTR_MAX];
-
+NL_ERROR nlError = NL_ERROR_SUCCESS;
OvsFlowGetInput getInput;
OvsFlowGetOutput getOutput;
NL_BUFFER nlBuf;
@@ -455,6 +462,11 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
goto done;
}
+if (nlAttrs[OVS_FLOW_ATTR_KEY] == NULL) {
+nlError = NL_ERROR_INVAL;
+goto done;
+}
+
keyAttrOffset = (UINT32)((PCHAR) nlAttrs[OVS_FLOW_ATTR_KEY] -
(PCHAR)nlMsgHdr);
@@ -532,6 +544,14 @@ _FlowNlGetCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
*replyLen += NlMsgSize(nlMsgOutHdr);
done:
+if (nlError != NL_ERROR_SUCCESS) {
+POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
+usrParamsCtx->outputBuffer;
+NlBuildErrorMsg(msgIn, msgError, nlError);
+*replyLen = msgError->nlMsg.nlmsgLen;
+rc = STATUS_SUCCESS;
+}
+
return rc;
}
diff --git a/datapath-windows/ovsext/Flow.h b/datapath-windows/ovsext/Flow.h
index e817bcf..02a72de 100644
--- a/datapath-windows/ovsext/Flow.h
+++ b/datapath-windows/ovsext/Flow.h
@@ -37,6 +37,12 @@ typedef struct _OvsFlow {
NL_ATTR actions[1];
} OvsFlow;
+typedef union _OvsU128{
+uint32_t u32[4];
+struct {
+uint64_t lo, hi;
+} u64;
+} OvsU128;
typedef struct _OvsLayers {
UINT32 l3Ofs; // IPv4, IPv6, ARP, or other L3 header.
--
1.9.5.msysgit.0
___
dev mailing list
dev@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailman_listinfo_dev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=CWsgHUxi6ExLXY798tmo3LJ4e3geGYp56lkcH-5cLCY&m=h-xnHaFVXtokcPzoZ2splmejx62S-xmfF3kpRTH09E4&s=jDEwGj_nNoRyr5TpRU2IUyAXEIYfICDpxyn7X_UJVJM&e=
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On 02/03/15 at 10:08am, Pravin Shelar wrote: > On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote: > > + flags = TUNNEL_KEY; > > + vxlan_port = vxlan_vport(vport); > > + if (vxlan_port->exts & VXLAN_F_GBP) > > + flags |= TUNNEL_VXLAN_OPT; > > > This does not allow GBP and non-GBP tunnel share vxlan port, since OVS > we have single vport shared between all vxlan end-points for given UDP > port. Correct, a non-GBP tunnel will ignore the GBP bits. Though a GBP tunnel will continue to receive non-GBP frames. This reflects what has been merged in the upstream kernel. The reason to require enabling individual extensions is to be able to support overlapping extensions, e.g. although using a different identifier bit, VXLAN-GPE is not compatible with VXLAN-GBP and the user can only enable one of the two extensions on a particular tunnel. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] datapath: update exact match lookup hash value to avoid hash collision
Currently, the exact match cache lookup uses 'skb->hash' as an index. In most cases, this value will be the same for pre and post recirculation lookup, threshing the exact match cache. This patch avoid this hash collision by using the rehashed value, by mixing in in the 'recirc_id', as the lookup index. Signed-off-by: Andy Zhou --- datapath/flow_table.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/datapath/flow_table.c b/datapath/flow_table.c index 2f8f3fb..8dad4c2 100644 --- a/datapath/flow_table.c +++ b/datapath/flow_table.c @@ -575,7 +575,7 @@ struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl, struct table_instance *ti = rcu_dereference(tbl->ti); struct mask_cache_entry *entries, *ce; struct sw_flow *flow; - u32 hash = skb_hash; + u32 hash; int seg; *n_mask_hit = 0; @@ -585,7 +585,14 @@ struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl, return flow_lookup(tbl, ti, ma, key, n_mask_hit, &mask_index); } + /* Pre and post recirulation flows usually have the same skb_hash +* value. To avoid hash collisions, rehash the 'skb_hash' with +* 'recirc_id'. */ + if (key->recirc_id) + skb_hash = jhash_1word(skb_hash, key->recirc_id); + ce = NULL; + hash = skb_hash; entries = this_cpu_ptr(tbl->mask_cache); /* Find the cache entry 'ce' to operate on. */ -- 1.9.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] possible issue about sending BFD packet?
Hi, I'm trying to set up BFD between two vlans created on different bridges running on different hosts. I noticed that unless bfd:bfd_remote_dst_mac is specified while setting up the BFD, the packet never leaves the host switch due to "skipping output to input port". Looking at RFC 5880/5881, there is no specification about the encapsulating packet itself, so I reckon this should be implementation dependent. I'm wondering if it makes sense to have a dummy (default) mac address as rmt_eth_dst so that bfd_should_process_flow does not flag the outgoing as something to be processed as a received packet? Thoughts? If so, I can send over a patch.. Thanks, Sabya ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath: update exact match lookup hash value to avoid hash collision
On Tue, Feb 3, 2015 at 2:09 PM, Andy Zhou wrote: > Currently, the exact match cache lookup uses 'skb->hash' as an index. > In most cases, this value will be the same for pre and post > recirculation lookup, threshing the exact match cache. This patch > avoid this hash collision by using the rehashed value, by mixing in > in the 'recirc_id', as the lookup index. > > Signed-off-by: Andy Zhou Acked-by: Pravin B Shelar ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On Tue, Feb 3, 2015 at 1:18 PM, Thomas Graf wrote: > On 02/03/15 at 10:08am, Pravin Shelar wrote: >> On Fri, Jan 30, 2015 at 6:36 AM, Thomas Graf wrote: >> > + flags = TUNNEL_KEY; >> > + vxlan_port = vxlan_vport(vport); >> > + if (vxlan_port->exts & VXLAN_F_GBP) >> > + flags |= TUNNEL_VXLAN_OPT; >> > >> This does not allow GBP and non-GBP tunnel share vxlan port, since OVS >> we have single vport shared between all vxlan end-points for given UDP >> port. > > Correct, a non-GBP tunnel will ignore the GBP bits. Though a GBP tunnel > will continue to receive non-GBP frames. This reflects what has been > merged in the upstream kernel. The reason to require enabling > individual extensions is to be able to support overlapping extensions, > e.g. although using a different identifier bit, VXLAN-GPE is not > compatible with VXLAN-GBP and the user can only enable one of the two > extensions on a particular tunnel. I agree port will continue to accept non GBP frames but sets TUNNEL_VXLAN_OPT which is odd. Since it is checking extension for the vport. Why not set TUNNEL_VXLAN_OPT according to received packet header/metadata? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] possible issue about sending BFD packet?
Hey, On Tue, Feb 3, 2015 at 2:19 PM, Sabyasachi Sengupta < sabyasachi.sengu...@alcatel-lucent.com> wrote: > > Hi, > > I'm trying to set up BFD between two vlans created on different bridges > running on different hosts. I noticed that unless bfd:bfd_remote_dst_mac is > specified while setting up the BFD, the packet never leaves the host switch > due to "skipping output to input port". Looking at RFC 5880/5881, there is > no specification about the encapsulating packet itself, so I reckon this > should be implementation dependent. I'm wondering if it makes sense to have > a dummy (default) mac address as rmt_eth_dst so that > bfd_should_process_flow does not flag the outgoing as something to be > processed as a received packet? Thoughts? If so, I can send over a patch.. > > bfd_should_process_flow() has nothing to do with sending bfd control packets. If you do not specify 'bfd_local_src_mac' or 'bfd_local_dst_mac', the inner packet will use the OpenFlow port's mac as src mac and 00:23:20:00:00:01 as dest mac. And you should have no issue sending the bfd control packets. Could you show me you ovs configuration (ovs-vsctl show output, and on which port you enable bfd)? I suspect there could be something wrong with the configuration... Thanks, Alex Wang, > Thanks, > Sabya > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On 02/03/15 at 02:25pm, Pravin Shelar wrote: > I agree port will continue to accept non GBP frames but sets > TUNNEL_VXLAN_OPT which is odd. Since it is checking extension for the > vport. > Why not set TUNNEL_VXLAN_OPT according to received packet header/metadata? Good point. I will change it to set TUNNEL_VXLAN_OPT if enabled and metadata is actually provided. Thanks for the reviews Pravin. I've already pushed patches 1-6 and 9-10 already. I will change this, into the symbol issue and resubmit the remaining patches. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] possible issue about sending BFD packet?
OK, here is what I have in one of my boxes (the other box has pretty much the same, except for slightly different mac address for the port/bridge): [sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-vsctl show 2677960f-42ff-42f0-b368-0bfbfa7b923d Bridge "br0" Port "br0" Interface "br0" type: internal Bridge "br1" Port "br1" Interface "br1" type: internal Port "eth2.10" Interface "eth2.10" [sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-ofctl dump-ports-desc br1 OFPST_PORT_DESC reply (xid=0x2): 1(eth2.10): addr:08:00:27:9d:1e:1e BFD enabled port config: 0 state: 0 current:1GB-FD COPPER AUTO_NEG advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG speed: 1000 Mbps now, 1000 Mbps max LOCAL(br1): addr:aa:bb:cc:dd:ee:00 config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max Here is what I did on both nodes: 1. created the bridge 2. created vlan and ifconfig up'd it 3. created the port with BFD config sudo ovs-vsctl add-port br1 eth2.10 -- set interface eth2.10 bfd:enable=true bfd:min_tx=500 bfd:min_rx=500 bfd:bfd_remote_dst_mac=00:ee:dd:cc:bb:aa But it seemed like the BFD packet never left the host as I got nothing on the eth2.10 interface in tcpdump, but yet there were lots of BFD send/receive messages in openvswitch.log (enabled vlog/set bfd:file:dbg). Upon gdb'ing I found that it ofproto_dpif_send_packet --> xlate_send_packet --> ofproto_dpif_execute_actions --> xlate_actions --> process_special --> bfd_should_process_flow, which returned SLOW_BFD. The problem went away after I added the last part of the #3 above (ie. the bfd_remote_dst_mac construct). Am I missing something here? On Tue, 3 Feb 2015, Alex Wang wrote: Hey, On Tue, Feb 3, 2015 at 2:19 PM, Sabyasachi Sengupta wrote: Hi, I'm trying to set up BFD between two vlans created on different bridges running on different hosts. I noticed that unless bfd:bfd_remote_dst_mac is specified while setting up the BFD, the packet never leaves the host switch due to "skipping output to input port". Looking at RFC 5880/5881, there is no specification about the encapsulating packet itself, so I reckon this should be implementation dependent. I'm wondering if it makes sense to have a dummy (default) mac address as rmt_eth_dst so that bfd_should_process_flow does not flag the outgoing as something to be processed as a received packet? Thoughts? If so, I can send over a patch.. bfd_should_process_flow() has nothing to do with sending bfd control packets. If you do not specify 'bfd_local_src_mac' or 'bfd_local_dst_mac', the inner packet will use the OpenFlow port's mac as src mac and 00:23:20:00:00:01 as dest mac. And you should have no issue sending the bfd control packets. Could you show me you ovs configuration (ovs-vsctl show output, and on which port you enable bfd)? I suspect there could be something wrong with the configuration... Thanks, Alex Wang, Thanks, Sabya ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] datapath: update exact match lookup hash value to avoid hash collision
Thanks, pushed to master and branch-2.3 > On Feb 3, 2015, at 2:19 PM, Pravin Shelar wrote: > > On Tue, Feb 3, 2015 at 2:09 PM, Andy Zhou wrote: >> Currently, the exact match cache lookup uses 'skb->hash' as an index. >> In most cases, this value will be the same for pre and post >> recirculation lookup, threshing the exact match cache. This patch >> avoid this hash collision by using the rehashed value, by mixing in >> in the 'recirc_id', as the lookup index. >> >> Signed-off-by: Andy Zhou > > Acked-by: Pravin B Shelar ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
On Mon, Feb 02, 2015 at 03:03:32PM -0800, Alex Wang wrote: > In 'ovs-dpctl dump-flows' output, we should only report the pmd > related info for 'dpif-netdev' datapath. However, current > implementation also reports uninitialized pmd info for > 'dpif-netlink' datapath, which is very confusing to users. > > This commit fixes it. > > Signed-off-by: Alex Wang It seems like another alternative would be for this code to just skip printing pmd ids when they're PMD_ID_NULL. If we do that, can we avoid adding a special case for netdev_dpif here? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] NEWS: Mention group support in version 2.1.
On Mon, Feb 02, 2015 at 10:54:07AM +0100, Thomas Graf wrote: > On 02/01/15 at 01:50pm, Ben Pfaff wrote: > > Someone asked about support and I realized that we forgot to mention it, > > so do so belatedly. > > > > Signed-off-by: Ben Pfaff > > Acked-by: Thomas Graf Thanks, applied to master. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 12/13] tunnel: Provide framework for tunnel extensions for VXLAN-GBP and others
On Fri, Jan 30, 2015 at 03:36:42PM +0100, Thomas Graf wrote: > 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 Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] possible issue about sending BFD packet?
Hey, Just repeated your config on my VM setup (two ubuntu 12.04 VMs on same ESX host, eth3 directly linked), ~/alex_dev/openvswitch# ovs-vsctl show a57a8953-c9fd-41c2-9cee-6bc57c2da649 Bridge "breth311" Port "breth311" Interface "breth311" type: internal Port "eth3.11" Interface "eth3.11" ovs_version: "2.3.90" Worked for me, I can tcpdump from eth3.11... Also, did you assign ip address to eth2.10? If you did, it should be assigned to br1's internal port. On Tue, Feb 3, 2015 at 2:39 PM, Sabyasachi Sengupta < sabyasachi.sengu...@alcatel-lucent.com> wrote: > > OK, here is what I have in one of my boxes (the other box has pretty much > the same, except for slightly different mac address for the port/bridge): > > [sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-vsctl show > 2677960f-42ff-42f0-b368-0bfbfa7b923d > Bridge "br0" > Port "br0" > Interface "br0" > type: internal > Bridge "br1" > Port "br1" > Interface "br1" > type: internal > Port "eth2.10" > Interface "eth2.10" > [sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-ofctl dump-ports-desc br1 > OFPST_PORT_DESC reply (xid=0x2): > 1(eth2.10): addr:08:00:27:9d:1e:1e BFD enabled port > config: 0 > state: 0 > current:1GB-FD COPPER AUTO_NEG > advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG > supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG > speed: 1000 Mbps now, 1000 Mbps max > LOCAL(br1): addr:aa:bb:cc:dd:ee:00 > config: PORT_DOWN > state: LINK_DOWN > speed: 0 Mbps now, 0 Mbps max > > Here is what I did on both nodes: > 1. created the bridge > 2. created vlan and ifconfig up'd it > 3. created the port with BFD config > sudo ovs-vsctl add-port br1 eth2.10 -- set interface eth2.10 > bfd:enable=true bfd:min_tx=500 bfd:min_rx=500 bfd:bfd_remote_dst_mac=00:ee: > dd:cc:bb:aa > > But it seemed like the BFD packet never left the host as I got nothing > on the eth2.10 interface in tcpdump, but yet there were lots of BFD > send/receive messages in openvswitch.log (enabled vlog/set bfd:file:dbg). > Upon gdb'ing I found that it ofproto_dpif_send_packet --> xlate_send_packet > --> ofproto_dpif_execute_actions --> xlate_actions --> process_special > --> bfd_should_process_flow, which returned SLOW_BFD. This is a correct calling sequence, > The problem went away > after I added the last part of the #3 above (ie. the bfd_remote_dst_mac > construct). Am I missing something here? > > > > On Tue, 3 Feb 2015, Alex Wang wrote: > > Hey, >> On Tue, Feb 3, 2015 at 2:19 PM, Sabyasachi Sengupta >> wrote: >> >> Hi, >> >> I'm trying to set up BFD between two vlans created on >> different bridges running on different hosts. I noticed that >> unless bfd:bfd_remote_dst_mac is specified while setting up >> the BFD, the packet never leaves the host switch due to >> "skipping output to input port". Looking at RFC 5880/5881, >> there is no specification about the encapsulating packet >> itself, so I reckon this should be implementation dependent. >> I'm wondering if it makes sense to have a dummy (default) mac >> address as rmt_eth_dst so that bfd_should_process_flow does >> not flag the outgoing as something to be processed as a >> received packet? Thoughts? If so, I can send over a patch.. >> >> >> bfd_should_process_flow() has nothing to do with sending bfd control >> packets. >> >> If you do not specify 'bfd_local_src_mac' or 'bfd_local_dst_mac', the >> inner >> packet will use the OpenFlow port's mac as src mac and 00:23:20:00:00:01 >> as dest mac. And you should have no issue sending the bfd control >> packets. >> >> Could you show me you ovs configuration (ovs-vsctl show output, and on >> which port you enable bfd)? I suspect there could be something wrong >> with the configuration... >> >> Thanks, >> Alex Wang, >> >> >> Thanks, >> Sabya >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> >> >> >> ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On Tue, Feb 3, 2015 at 2:33 PM, Thomas Graf wrote: > On 02/03/15 at 02:25pm, Pravin Shelar wrote: >> I agree port will continue to accept non GBP frames but sets >> TUNNEL_VXLAN_OPT which is odd. Since it is checking extension for the >> vport. >> Why not set TUNNEL_VXLAN_OPT according to received packet header/metadata? > > Good point. I will change it to set TUNNEL_VXLAN_OPT if enabled and > metadata is actually provided. 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 VXLAN port (on the userspace side) and have another that is vanilla then we shouldn't silently use the extension for everything. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 13/13] ofproto: Add NXM_NX_TUN_GBP_ID and NXM_NX_TUN_GBP_FLAGS
On Fri, Jan 30, 2015 at 03:36:43PM +0100, Thomas Graf wrote:
> 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 carried to/from the datapath using the attribute
> OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS.
>
> [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy-00
>
> Signed-off-by: Madhu Challa
Applying only this patch and the one before it, I get build assertions
in flow.h:
In file included from ../ofproto/bond.c:19:
In file included from ../ofproto/bond.h:22:
In file included from ../ofproto/ofproto-provider.h:37:
In file included from ../lib/classifier.h:217:
In file included from ../lib/match.h:20:
../lib/flow.h:141:1: error: bit-field 'build_assert_failed' has negative
width
(-1)
BUILD_ASSERT_DECL(sizeof(struct flow) % sizeof(uint64_t) == 0);
^
../lib/util.h:55:42: note: expanded from macro 'BUILD_ASSERT_DECL'
extern int (*build_assert(void))[BUILD_ASSERT__(EXPR)]
^
../lib/util.h:48:38: note: expanded from macro 'BUILD_ASSERT__'
sizeof(struct { unsigned int build_assert_failed : (EXPR) ? 1 : -1;
})
^
I build on 32-bit so that's probably key to the problem. (That's
actually the only reason I stick with a 32-bit OS: I find problems that
others don't, early.)
I see other compiler errors but I think that's only because I didn't
apply the other patches.
Please use a 0x prefix (or "%#"PRIx8 in this case) for printing fields
in hex, so that output is unambiguous:
+if (wc->masks.tunnel.gbp_flags) {
+ds_put_format(s, "tun_gbp_flags=%"PRIx8",", tnl->gbp_flags);
+}
ofp_print_packet_in() prints gbp_flags in decimal whereas it's in
hexadecimal everywhere else.
Here, I think the hole is shown in the wrong place; I don't think a hole
would go in the middle of a bunch of 1-byte members:
struct flow_tnl {
ovs_be64 tun_id;
ovs_be32 ip_src;
ovs_be32 ip_dst;
uint16_t flags;
+ovs_be16 gbp_id;
+uint8_t gbp_flags;
+/* 1 byte hole */
uint8_t ip_tos;
uint8_t ip_ttl;
ovs_be16 tp_src;
ovs_be16 tp_dst;
};
The diagram added to the manpage looks ugly in PDF or HTML output. You
can use \f(CR (which is unfortunately groff-only as far as I know) to
fix that, e.g.:
diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
index acb282a..d548923 100644
--- a/utilities/ovs-ofctl.8.in
+++ b/utilities/ovs-ofctl.8.in
@@ -,11 +,11 @@ VXLAN tunnel endpoint.
The \fBtun_gbp_flags\fR field has the following format:
.IP
.in +2
-+-+-+-+-+-+-+-+-+
+\f(CR+-+-+-+-+-+-+-+-+\fR
.br
-|-|D|-|-|A|-|-|-|
+\f(CR|-|D|-|-|A|-|-|-|\fR
.br
-+-+-+-+-+-+-+-+-+
+\f(CR+-+-+-+-+-+-+-+-+\fR
.B D :=
Don't Learn bit. When set, this bit indicates that the egress
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ofp-util: Issue error when OFPGC_DELETE command includes buckets.
On Mon, Feb 02, 2015 at 11:57:55AM +0100, Thomas Graf wrote: > On 01/30/15 at 02:24pm, Ben Pfaff wrote: > > An OFPGC_DELETE command deletes a whole group, including all of its > > buckets, and so it doesn't make sense for the command itself to include any > > specification of buckets. > > > > ONF-JIRA: EXT-510 > > Signed-off-by: Ben Pfaff > > LGTM > Acked-by: Thomas Graf Thanks! Applied to master. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ofproto: add support of OFPR_ACTION_SET as packet-in reason for OF1.4+
On Mon, Feb 02, 2015 at 04:18:19PM -0800, Shu Shen wrote:
> This patch adds support for OFPR_ACTION_SET as the packet-in reason when
> a Packet-In message is triggered by an output action within an
> action-set. By default reason code OFPR_ACTION_SET is enabled for async
> messages when Openflow 1.4+ is used. A test case is included.
>
> Signed-off-by: Shu Shen
Thanks for the contribution.
I think that this will report OFPR_ACTION_SET in the case where the
action set contains an output action then an "apply_actions" sends a
packet to the controller. That is, with a flow table something like
this:
table=0, actions=write_actions(controller),goto_table:1
table=1, actions=controller
I think that both "controller" actions will use OFPR_ACTION_SET.
This needs {} around each of the conditional statements (see
CodingStyle.md):
> + {
> + enum ofp_packet_in_reason reason = OFPR_ACTION;
> + if (ctx->in_group)
> + reason = OFPR_GROUP;
> +else if (OFPP_UNSET != ctx->xin->flow.actset_output)
> +reason = OFPR_ACTION_SET;
> + execute_controller_action(ctx, max_len, reason, 0);
> + }
Thanks,
Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC v2 1/8] Documentation: Add documentation of group selection method property
On Fri, Jan 30, 2015 at 11:41:49AM +0900, Simon Horman wrote: > Signed-off-by: Simon Horman Thanks, I'm happy with this documentation. I have a question about the abbreviation NMX for Netronome. At first glance, to me it looks like a typo for NXM. Is NMX a commonly used short form of Netronome? If so, then let's stick with it, otherwise I'd use something a little different, maybe NTR. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] docs: directly convert dot diagrams into eps for generating PDF
On Fri, Jan 30, 2015 at 04:02:40PM -0800, Shu Shen wrote: > The previous workflow is to convert dot diagrams into .pic format and > embed into manpages; double borders and arrows were not used in dot but > introduced in .pic conversion; edge routing in .pic was also worse than > dot. > > The updated workflow specifies directly in dot diagram double > boarders for "root set" nodes and solid/bold styles and arrows for > edges. The converted .eps diagram has improved routing. The .eps diagram > is embedded into PDF using groff PSPIC marco package when converting the > manpages. PSPIC package is automatically loaded by groff when output to > PS/PDF. > > In addition, 'constraint=false' option is removed from weak > references to allow positioning of node boxes to avoid overlapping > between multiple edges between "Mirror" and "Port" in > ovs-vswitchd.conf.db. > > Signed-off-by: Shu Shen OK, now it doesn't generate build errors, but now that I realize what's going on, I don't know how manpages with dependencies like this get installed. Where does vswitch.eps go in the file system, and how does it get there? I see, for example, that "make install" puts vswitch.eps in /usr/share/man/mane, which can't be right. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/2] mcast_snoop: make mcast_fport_bundle generic
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 taken me a long time to review this patch. As usual, I have been busy; most recently, I was out the last five days to an out-of-town corporate event where they kept us busy from 7am to 10pm or later. Hardly had time to breathe, let along review patches. I need a little bit of help understanding this patch. In particular, the changes remove a 'vlan' parameter from a lot of function prototypes, and I don't see anything replace it. Was the VLAN somehow unused previously? I'd like to understand why it was needed before and somehow not needed now. Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/2] mcast-snoop: Add support to control Reports forwarding
On Tue, Jan 20, 2015 at 10:04:01AM -0200, Flavio Leitner wrote: > The RFC4541 section 2.1.1 item 1 allows the snooping switch > to provide an administrative control to allow Report messages > to be flooded to ports not connected to multicast routers. > > Signed-off-by: Flavio Leitner I'm happy with this patch once I understand patch 1. Acked-by: Ben Pfaff Thanks for maintaining the multicast snooping code so well, by the way. If I recall correctly you added this feature in response to a user request, which is great. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] hello
Hello dear. I know you maybe wondering how i got your email address, do not be astonish about it,I once came across your mail through internet browsing. and i decide to write you message so that we will get to know each other and become closed friend. Your friend Stella. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
On Tue, Feb 3, 2015 at 2:55 PM, Ben Pfaff wrote: > On Mon, Feb 02, 2015 at 03:03:32PM -0800, Alex Wang wrote: > > In 'ovs-dpctl dump-flows' output, we should only report the pmd > > related info for 'dpif-netdev' datapath. However, current > > implementation also reports uninitialized pmd info for > > 'dpif-netlink' datapath, which is very confusing to users. > > > > This commit fixes it. > > > > Signed-off-by: Alex Wang > > It seems like another alternative would be for this code to just skip > printing pmd ids when they're PMD_ID_NULL. If we do that, can we avoid > adding a special case for netdev_dpif here? > Yes, that should be the way to fix it... somehow I overlooked it... I'll resend it. Thanks, Alex Wang, ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
On Tue, Feb 3, 2015 at 4:20 PM, Alex Wang wrote: > > > On Tue, Feb 3, 2015 at 2:55 PM, Ben Pfaff wrote: >> >> On Mon, Feb 02, 2015 at 03:03:32PM -0800, Alex Wang wrote: >> > In 'ovs-dpctl dump-flows' output, we should only report the pmd >> > related info for 'dpif-netdev' datapath. However, current >> > implementation also reports uninitialized pmd info for >> > 'dpif-netlink' datapath, which is very confusing to users. >> > >> > This commit fixes it. >> > >> > Signed-off-by: Alex Wang >> >> It seems like another alternative would be for this code to just skip >> printing pmd ids when they're PMD_ID_NULL. If we do that, can we avoid >> adding a special case for netdev_dpif here? > > > Yes, that should be the way to fix it... somehow I overlooked it... I'll > resend it. Thanks! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH-V2] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
In 'ovs-dpctl dump-flows' output, we should only report the pmd
related info for 'dpif-netdev' datapath. However, current
implementation also reports uninitialized pmd info for
'dpif-netlink' datapath, which is very confusing to users.
This commit fixes it.
Signed-off-by: Alex Wang
---
PATCH->V2:
- fix it using the correct way.
---
lib/dpif-netlink.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index de43d80..1d8abdf 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -1429,9 +1429,9 @@ dpif_netlink_flow_to_dpif_flow(struct dpif *dpif, struct
dpif_flow *dpif_flow,
dpif_flow->actions = datapath_flow->actions;
dpif_flow->actions_len = datapath_flow->actions_len;
dpif_flow->ufid_present = datapath_flow->ufid_present;
+dpif_flow->pmd_id = PMD_ID_NULL;
if (datapath_flow->ufid_present) {
dpif_flow->ufid = datapath_flow->ufid;
-dpif_flow->pmd_id = PMD_ID_NULL;
} else {
ovs_assert(datapath_flow->key && datapath_flow->key_len);
dpif_flow_hash(dpif, datapath_flow->key, datapath_flow->key_len,
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC v2 1/8] Documentation: Add documentation of group selection method property
On Tue, Feb 03, 2015 at 03:41:04PM -0800, Ben Pfaff wrote: > On Fri, Jan 30, 2015 at 11:41:49AM +0900, Simon Horman wrote: > > Signed-off-by: Simon Horman > > Thanks, I'm happy with this documentation. > > I have a question about the abbreviation NMX for Netronome. At first > glance, to me it looks like a typo for NXM. Is NMX a commonly used > short form of Netronome? If so, then let's stick with it, otherwise I'd > use something a little different, maybe NTR. Hi Ben, I agree that NMX and NXM look quite similar and to be honest I confused myself several times by that choice. I am not aware of any other use of NMX so I think it is fine to change it. But although I feel that I'm missing something terribly obvious: what is NTR an abbreviation of? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC v2 1/8] Documentation: Add documentation of group selection method property
On Wed, Feb 04, 2015 at 10:01:53AM +0900, Simon Horman wrote: > On Tue, Feb 03, 2015 at 03:41:04PM -0800, Ben Pfaff wrote: > > On Fri, Jan 30, 2015 at 11:41:49AM +0900, Simon Horman wrote: > > > Signed-off-by: Simon Horman > > > > Thanks, I'm happy with this documentation. > > > > I have a question about the abbreviation NMX for Netronome. At first > > glance, to me it looks like a typo for NXM. Is NMX a commonly used > > short form of Netronome? If so, then let's stick with it, otherwise I'd > > use something a little different, maybe NTR. > > Hi Ben, > > I agree that NMX and NXM look quite similar and to be honest I confused > myself several times by that choice. I am not aware of any other use > of NMX so I think it is fine to change it. But although I feel that > I'm missing something terribly obvious: what is NTR an abbreviation of? NeTRonome. Feel free to pick a different abbreviation; that was just the first that occurred to me. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH-V2] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
On Tue, Feb 03, 2015 at 04:39:19PM -0800, Alex Wang wrote: > In 'ovs-dpctl dump-flows' output, we should only report the pmd > related info for 'dpif-netdev' datapath. However, current > implementation also reports uninitialized pmd info for > 'dpif-netlink' datapath, which is very confusing to users. > > This commit fixes it. > > Signed-off-by: Alex Wang Acked-by: Ben Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC v2 1/8] Documentation: Add documentation of group selection method property
On Tue, Feb 03, 2015 at 05:15:01PM -0800, Ben Pfaff wrote: > On Wed, Feb 04, 2015 at 10:01:53AM +0900, Simon Horman wrote: > > On Tue, Feb 03, 2015 at 03:41:04PM -0800, Ben Pfaff wrote: > > > On Fri, Jan 30, 2015 at 11:41:49AM +0900, Simon Horman wrote: > > > > Signed-off-by: Simon Horman > > > > > > Thanks, I'm happy with this documentation. > > > > > > I have a question about the abbreviation NMX for Netronome. At first > > > glance, to me it looks like a typo for NXM. Is NMX a commonly used > > > short form of Netronome? If so, then let's stick with it, otherwise I'd > > > use something a little different, maybe NTR. > > > > Hi Ben, > > > > I agree that NMX and NXM look quite similar and to be honest I confused > > myself several times by that choice. I am not aware of any other use > > of NMX so I think it is fine to change it. But although I feel that > > I'm missing something terribly obvious: what is NTR an abbreviation of? > > NeTRonome. Feel free to pick a different abbreviation; that was just > the first that occurred to me. Thanks! NTR seems fine to me. Should I re-spin the series? Or would you prefer to review other portions of it as is? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC v2 1/8] Documentation: Add documentation of group selection method property
On Tue, Feb 3, 2015 at 5:23 PM, Simon Horman wrote: > On Tue, Feb 03, 2015 at 05:15:01PM -0800, Ben Pfaff wrote: >> On Wed, Feb 04, 2015 at 10:01:53AM +0900, Simon Horman wrote: >> > On Tue, Feb 03, 2015 at 03:41:04PM -0800, Ben Pfaff wrote: >> > > On Fri, Jan 30, 2015 at 11:41:49AM +0900, Simon Horman wrote: >> > > > Signed-off-by: Simon Horman >> > > >> > > Thanks, I'm happy with this documentation. >> > > >> > > I have a question about the abbreviation NMX for Netronome. At first >> > > glance, to me it looks like a typo for NXM. Is NMX a commonly used >> > > short form of Netronome? If so, then let's stick with it, otherwise I'd >> > > use something a little different, maybe NTR. >> > >> > Hi Ben, >> > >> > I agree that NMX and NXM look quite similar and to be honest I confused >> > myself several times by that choice. I am not aware of any other use >> > of NMX so I think it is fine to change it. But although I feel that >> > I'm missing something terribly obvious: what is NTR an abbreviation of? >> >> NeTRonome. Feel free to pick a different abbreviation; that was just >> the first that occurred to me. > > Thanks! > > NTR seems fine to me. Should I re-spin the series? > Or would you prefer to review other portions of it as is? It seems like a waste to have you respin the series just for this. I'll continue to review it; I've just been working on other things for the moment (honestly I didn't expect you to reply for several hours). ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] docs: directly convert dot diagrams into eps for generating PDF
Let me think about it - seems there is a need to separate the eps files from install-man target. It's really the dist-docs scripts that needs the eps files. Shu > On Feb 3, 2015, at 3:52 PM, Ben Pfaff wrote: > >> On Fri, Jan 30, 2015 at 04:02:40PM -0800, Shu Shen wrote: >> The previous workflow is to convert dot diagrams into .pic format and >> embed into manpages; double borders and arrows were not used in dot but >> introduced in .pic conversion; edge routing in .pic was also worse than >> dot. >> >> The updated workflow specifies directly in dot diagram double >> boarders for "root set" nodes and solid/bold styles and arrows for >> edges. The converted .eps diagram has improved routing. The .eps diagram >> is embedded into PDF using groff PSPIC marco package when converting the >> manpages. PSPIC package is automatically loaded by groff when output to >> PS/PDF. >> >> In addition, 'constraint=false' option is removed from weak >> references to allow positioning of node boxes to avoid overlapping >> between multiple edges between "Mirror" and "Port" in >> ovs-vswitchd.conf.db. >> >> Signed-off-by: Shu Shen > > OK, now it doesn't generate build errors, but now that I realize what's > going on, I don't know how manpages with dependencies like this get > installed. Where does vswitch.eps go in the file system, and how does > it get there? I see, for example, that "make install" puts vswitch.eps > in /usr/share/man/mane, which can't be right. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] netdev-dpdk: Allow changing NON_PMD_CORE_ID for testing purpose.
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 OVS.
This commit fixes the assertion and allows changing NON_PMD_CORE_ID.
Signed-off-by: Alex Wang
---
lib/dpctl.c |2 +-
lib/dpif-netdev.h |1 -
lib/netdev-dpdk.c | 12 ++--
lib/netdev-dpdk.h |2 ++
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/lib/dpctl.c b/lib/dpctl.c
index 4c2614b..125023c 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -31,11 +31,11 @@
#include "dirs.h"
#include "dpctl.h"
#include "dpif.h"
-#include "dpif-netdev.h"
#include "dynamic-string.h"
#include "flow.h"
#include "match.h"
#include "netdev.h"
+#include "netdev-dpdk.h"
#include "netlink.h"
#include "odp-util.h"
#include "ofp-parse.h"
diff --git a/lib/dpif-netdev.h b/lib/dpif-netdev.h
index d811507..410fcfa 100644
--- a/lib/dpif-netdev.h
+++ b/lib/dpif-netdev.h
@@ -42,7 +42,6 @@ static inline void dp_packet_pad(struct ofpbuf *b)
#define NR_QUEUE 1
#define NR_PMD_THREADS 1
-#define NON_PMD_CORE_ID 0
#ifdef __cplusplus
}
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 0ede200..391695f 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -1553,8 +1553,8 @@ pmd_thread_setaffinity_cpu(int cpu)
VLOG_ERR("Thread affinity error %d",err);
return err;
}
-/* lcore_id 0 is reseved for use by non pmd threads. */
-ovs_assert(cpu);
+/* NON_PMD_CORE_ID is reserved for use by non pmd threads. */
+ovs_assert(cpu != NON_PMD_CORE_ID);
RTE_PER_LCORE(_lcore_id) = cpu;
return 0;
@@ -1563,13 +1563,13 @@ pmd_thread_setaffinity_cpu(int cpu)
void
thread_set_nonpmd(void)
{
-/* We have to use 0 to allow non pmd threads to perform certain DPDK
- * operations, like rte_eth_dev_configure(). */
-RTE_PER_LCORE(_lcore_id) = 0;
+/* We have to use NON_PMD_CORE_ID to allow non-pmd threads to perform
+ * certain DPDK operations, like rte_eth_dev_configure(). */
+RTE_PER_LCORE(_lcore_id) = NON_PMD_CORE_ID;
}
static bool
thread_is_pmd(void)
{
-return rte_lcore_id() != 0;
+return rte_lcore_id() != NON_PMD_CORE_ID;
}
diff --git a/lib/netdev-dpdk.h b/lib/netdev-dpdk.h
index c24d6da..9a47165 100644
--- a/lib/netdev-dpdk.h
+++ b/lib/netdev-dpdk.h
@@ -5,6 +5,8 @@
struct dpif_packet;
+#define NON_PMD_CORE_ID 0
+
#ifdef DPDK_NETDEV
#include
--
1.7.9.5
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ofproto: add support of OFPR_ACTION_SET as packet-in reason for OF1.4+
> On Feb 3, 2015, at 3:39 PM, Ben Pfaff wrote:
>
>> On Mon, Feb 02, 2015 at 04:18:19PM -0800, Shu Shen wrote:
>> This patch adds support for OFPR_ACTION_SET as the packet-in reason when
>> a Packet-In message is triggered by an output action within an
>> action-set. By default reason code OFPR_ACTION_SET is enabled for async
>> messages when Openflow 1.4+ is used. A test case is included.
>>
>> Signed-off-by: Shu Shen
>
> Thanks for the contribution.
>
> I think that this will report OFPR_ACTION_SET in the case where the
> action set contains an output action then an "apply_actions" sends a
> packet to the controller. That is, with a flow table something like
> this:
>
>table=0, actions=write_actions(controller),goto_table:1
>table=1, actions=controller
>
> I think that both "controller" actions will use OFPR_ACTION_SET.
Thanks for catching this. I'm updating the test case for better coverage and
will revise the patch as well.
>
> This needs {} around each of the conditional statements (see
> CodingStyle.md):
Will update the code.
>> +{
>> +enum ofp_packet_in_reason reason = OFPR_ACTION;
>> +if (ctx->in_group)
>> +reason = OFPR_GROUP;
>> +else if (OFPP_UNSET != ctx->xin->flow.actset_output)
>> +reason = OFPR_ACTION_SET;
>> +execute_controller_action(ctx, max_len, reason, 0);
>> +}
>
> Thanks,
>
> Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-command-completion: Complete on file path by default.
On Tue, Feb 3, 2015 at 8:50 AM, Ben Pfaff wrote: > Acked-by: Ben Pfaff > Thanks, I manually tested it, Will keep using it and respond to any future comment, For now, applied to master, Thanks, Alex Wang, ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/13] datapath: Support VXLAN Group Policy extension
On Tue, Feb 3, 2015 at 3:18 PM, Jesse Gross wrote: > On Tue, Feb 3, 2015 at 2:33 PM, Thomas Graf wrote: >> On 02/03/15 at 02:25pm, Pravin Shelar wrote: >>> I agree port will continue to accept non GBP frames but sets >>> TUNNEL_VXLAN_OPT which is odd. Since it is checking extension for the >>> vport. >>> Why not set TUNNEL_VXLAN_OPT according to received packet header/metadata? >> >> Good point. I will change it to set TUNNEL_VXLAN_OPT if enabled and >> metadata is actually provided. > > 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 VXLAN port > (on the userspace side) and have another that is vanilla then we > shouldn't silently use the extension for everything. One other thought on this: Is it really right for the kernel to ignore unknown extensions? It seems like if the user has requested a particular mode and it just silently doesn't take effect because the kernel doesn't know about it that's not really great. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH-V2] ovs-dpctl: Do not report pmd info for 'dpif-netlink' datapath.
Thx very much for the review, applied to master, On Tue, Feb 3, 2015 at 5:16 PM, Ben Pfaff wrote: > On Tue, Feb 03, 2015 at 04:39:19PM -0800, Alex Wang wrote: > > In 'ovs-dpctl dump-flows' output, we should only report the pmd > > related info for 'dpif-netdev' datapath. However, current > > implementation also reports uninitialized pmd info for > > 'dpif-netlink' datapath, which is very confusing to users. > > > > This commit fixes it. > > > > Signed-off-by: Alex Wang > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
Thanks Ben! For user space tunneling patches, I guess they will be under Apache License 2 which also means the patent licenses will be granted by the patches distributor/patent holder (i.e. Nicira). On Wed, Feb 4, 2015 at 12:45 AM, Ben Pfaff wrote: > On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: >> One question on STT IP, is it free to use STT in commercial products? >> I believe Nicira has patents on this. > > Assuming that Nicira does, the patches are being offered by the patent > holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] (no subject)
-- Kontakt über E-Mail-für sichern und ungesichert Darlehen. leihen Menge aus 5.000€ zu Maximum Menge von 5000.000€. Kontakt über E-Mail. guptasur...@qq.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] (no subject)
-- Kontakt über E-Mail-für sichern und ungesichert Darlehen. leihen Menge aus 5.000€ zu Maximum Menge von 5000.000€. Kontakt über E-Mail. guptasur...@qq.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
Userspace code is generally licensed under Apache 2 but I don't think anyone has proposed such patches to date. On Tue, Feb 3, 2015 at 6:07 PM, John Xiao wrote: > Thanks Ben! > > For user space tunneling patches, I guess they will be under Apache > License 2 which also means the patent licenses will be granted by the > patches distributor/patent holder (i.e. Nicira). > > On Wed, Feb 4, 2015 at 12:45 AM, Ben Pfaff wrote: >> On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: >>> One question on STT IP, is it free to use STT in commercial products? >>> I believe Nicira has patents on this. >> >> Assuming that Nicira does, the patches are being offered by the patent >> holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
Thanks Jesse! That's true that there is no such patch yet. Pravin just mentioned "I will send out OVS userspace patch on ovs-dev mailing list." in http://marc.info/?l=linux-netdev&m=142257416618642&w=2 On Wed, Feb 4, 2015 at 11:50 AM, Jesse Gross wrote: > Userspace code is generally licensed under Apache 2 but I don't think > anyone has proposed such patches to date. > > On Tue, Feb 3, 2015 at 6:07 PM, John Xiao wrote: >> Thanks Ben! >> >> For user space tunneling patches, I guess they will be under Apache >> License 2 which also means the patent licenses will be granted by the >> patches distributor/patent holder (i.e. Nicira). >> >> On Wed, Feb 4, 2015 at 12:45 AM, Ben Pfaff wrote: >>> On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: One question on STT IP, is it free to use STT in commercial products? I believe Nicira has patents on this. >>> >>> Assuming that Nicira does, the patches are being offered by the patent >>> holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
I think he just meant the pieces to configure the kernel implementation. Realistically, nobody on this list is going to be able to give you a legal opinion. You should talk to a lawyer to determine your rights as far as patents go. On Tue, Feb 3, 2015 at 8:11 PM, John Xiao wrote: > Thanks Jesse! > > That's true that there is no such patch yet. > Pravin just mentioned "I will send out OVS userspace patch on ovs-dev > mailing list." in > http://marc.info/?l=linux-netdev&m=142257416618642&w=2 > > On Wed, Feb 4, 2015 at 11:50 AM, Jesse Gross wrote: >> Userspace code is generally licensed under Apache 2 but I don't think >> anyone has proposed such patches to date. >> >> On Tue, Feb 3, 2015 at 6:07 PM, John Xiao wrote: >>> Thanks Ben! >>> >>> For user space tunneling patches, I guess they will be under Apache >>> License 2 which also means the patent licenses will be granted by the >>> patches distributor/patent holder (i.e. Nicira). >>> >>> On Wed, Feb 4, 2015 at 12:45 AM, Ben Pfaff wrote: On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: > One question on STT IP, is it free to use STT in commercial products? > I believe Nicira has patents on this. Assuming that Nicira does, the patches are being offered by the patent holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. >>> ___ >>> dev mailing list >>> dev@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
Thanks Jesse. Sorry I misunderstood that. On Wed, Feb 4, 2015 at 12:18 PM, Jesse Gross wrote: > I think he just meant the pieces to configure the kernel implementation. > > Realistically, nobody on this list is going to be able to give you a > legal opinion. You should talk to a lawyer to determine your rights as > far as patents go. > > On Tue, Feb 3, 2015 at 8:11 PM, John Xiao wrote: >> Thanks Jesse! >> >> That's true that there is no such patch yet. >> Pravin just mentioned "I will send out OVS userspace patch on ovs-dev >> mailing list." in >> http://marc.info/?l=linux-netdev&m=142257416618642&w=2 >> >> On Wed, Feb 4, 2015 at 11:50 AM, Jesse Gross wrote: >>> Userspace code is generally licensed under Apache 2 but I don't think >>> anyone has proposed such patches to date. >>> >>> On Tue, Feb 3, 2015 at 6:07 PM, John Xiao wrote: Thanks Ben! For user space tunneling patches, I guess they will be under Apache License 2 which also means the patent licenses will be granted by the patches distributor/patent holder (i.e. Nicira). On Wed, Feb 4, 2015 at 12:45 AM, Ben Pfaff wrote: > On Tue, Feb 03, 2015 at 12:12:41PM +0800, John Xiao wrote: >> One question on STT IP, is it free to use STT in commercial products? >> I believe Nicira has patents on this. > > Assuming that Nicira does, the patches are being offered by the patent > holder under GPLv2, see http://en.swpat.org/wiki/GPLv2_and_patents. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v2] ofproto: add support of OFPR_ACTION_SET as packet-in reason for OF1.4+
This patch adds support for OFPR_ACTION_SET as the packet-in reason when
a Packet-In message is triggered by an output action within an
action-set. By default reason code OFPR_ACTION_SET is enabled for async
messages when Openflow 1.4+ is used. A test case is included.
Signed-off-by: Shu Shen
---
Changes in V2:
- A new flag in_action_set is added to xlate_ctx to indicate the output action
is part of action_set. This corrects earlier detection method.
- Test cases for OFPR_GROUP and OFPR_ACTION_SET packet-in reasons are combined
and coverage for OFPR_ACTION is also added.
DESIGN.md| 1 +
OPENFLOW-1.1+.md | 2 +-
ofproto/connmgr.c| 5 +++
ofproto/ofproto-dpif-xlate.c | 15 +++--
tests/ofproto-dpif.at| 72
5 files changed, 80 insertions(+), 15 deletions(-)
diff --git a/DESIGN.md b/DESIGN.md
index ff5bdf4..4d94c2d 100644
--- a/DESIGN.md
+++ b/DESIGN.md
@@ -54,6 +54,7 @@ sent, an entry labeled "---" means that the message is
suppressed.
OFPR_NO_MATCH yes ---
OFPR_ACTIONyes ---
OFPR_INVALID_TTL --- ---
+OFPR_ACTION_SET (OF1.4+) yes ---
OFPR_GROUP (OF1.4+)yes ---
OFPT_FLOW_REMOVED / NXT_FLOW_REMOVED
diff --git a/OPENFLOW-1.1+.md b/OPENFLOW-1.1+.md
index 967f906..7911406 100644
--- a/OPENFLOW-1.1+.md
+++ b/OPENFLOW-1.1+.md
@@ -197,7 +197,7 @@ OpenFlow 1.4 features are listed in the previous section.
* More descriptive reasons for packet-in
Distinguish OFPR_APPLY_ACTION, OFPR_ACTION_SET, OFPR_GROUP,
OFPR_PACKET_OUT. NO_MATCH was renamed to OFPR_TABLE_MISS.
-(OFPR_GROUP is now supported)
+(OFPR_ACTION_SET and OFPR_GROUP are now supported)
[EXT-136]
[required for OF1.4+]
diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
index 3d69122..82143aa 100644
--- a/ofproto/connmgr.c
+++ b/ofproto/connmgr.c
@@ -1000,6 +1000,10 @@ ofconn_set_protocol(struct ofconn *ofconn, enum
ofputil_protocol protocol)
uint32_t *master = ofconn->master_async_config;
uint32_t *slave = ofconn->slave_async_config;
+/* OFPR_ACTION_SET is not supported before OF1.4 */
+master[OAM_PACKET_IN] &= ~(1u << OFPR_ACTION_SET);
+slave [OAM_PACKET_IN] &= ~(1u << OFPR_ACTION_SET);
+
/* OFPR_GROUP is not supported before OF1.4 */
master[OAM_PACKET_IN] &= ~(1u << OFPR_GROUP);
slave [OAM_PACKET_IN] &= ~(1u << OFPR_GROUP);
@@ -1252,6 +1256,7 @@ ofconn_flush(struct ofconn *ofconn)
* reasons itself. */
master[OAM_PACKET_IN] = ((1u << OFPR_NO_MATCH)
| (1u << OFPR_ACTION)
+ | (1u << OFPR_ACTION_SET)
| (1u << OFPR_GROUP));
master[OAM_PORT_STATUS] = ((1u << OFPPR_ADD)
| (1u << OFPPR_DELETE)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 0786513..8a47531 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -196,6 +196,7 @@ struct xlate_ctx {
int recurse;/* Current resubmit nesting depth. */
int resubmits; /* Total number of resubmits. */
bool in_group; /* Currently translating ofgroup, if true. */
+bool in_action_set; /* Currently translating action_set, if true.
*/
uint32_t orig_skb_priority; /* Priority when packet arrived. */
uint8_t table_id; /* OpenFlow table ID where flow was found. */
@@ -3429,8 +3430,15 @@ xlate_output_action(struct xlate_ctx *ctx,
flood_packets(ctx, true);
break;
case OFPP_CONTROLLER:
-execute_controller_action(ctx, max_len,
- ctx->in_group ? OFPR_GROUP : OFPR_ACTION, 0);
+{
+enum ofp_packet_in_reason reason = OFPR_ACTION;
+if (ctx->in_group){
+reason = OFPR_GROUP;
+}else if (ctx->in_action_set){
+reason = OFPR_ACTION_SET;
+}
+execute_controller_action(ctx, max_len, reason, 0);
+}
break;
case OFPP_NONE:
break;
@@ -3712,9 +3720,11 @@ xlate_action_set(struct xlate_ctx *ctx)
uint64_t action_list_stub[1024 / 64];
struct ofpbuf action_list;
+ctx->in_action_set = true;
ofpbuf_use_stub(&action_list, action_list_stub, sizeof action_list_stub);
ofpacts_execute_action_set(&action_list, &ctx->action_set);
do_xlate_actions(ofpbuf_data(&action_list), ofpbuf_size(&action_list),
ctx);
+ctx->in_action_set = false;
ofpbuf_uninit(&action_list);
}
@@ -4398,6 +4408,7 @@ xlate_actions(struct xlate_in *xin, struct xlate_out
*xout)
ctx.recurse = 0;
ctx.resubmits = 0;
ctx.in_group = false;
+
Re: [ovs-dev] [ovs-discuss] Open vSwitch STT support
2015-02-03 22:27 GMT+03:00 Pravin Shelar : > I do not have any plans of pushing STT to upstream kernel. I do not > think increased STT usage will help us getting STT upstream in future. > STT is useful tunneling protocol regardless of whether it is upstream > or not and that is motivation of merging it to OVS repo. > 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? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH v3] docs: directly convert dot diagrams into eps for generating PDF
The previous workflow is to convert dot diagrams into .pic format and
embed into manpages; double borders and arrows were not used in dot but
introduced in .pic conversion; edge routing in .pic was also worse than
dot.
The updated workflow specifies directly in dot diagram double
boarders for "root set" nodes and solid/bold styles and arrows for
edges. The converted .eps diagram has improved routing. The .eps diagram
is embedded into PDF using groff PSPIC marco package when converting the
manpages. PSPIC package is automatically loaded by groff when output to
PS/PDF.
In addition, 'constraint=false' option is removed from weak
references to allow positioning of node boxes to avoid overlapping
between multiple edges between "Mirror" and "Port" in
ovs-vswitchd.conf.db.
Signed-off-by: Shu Shen
---
Changes made in V3:
- .eps files are no longer added to manpages (man_MANS). They are listed as
dependancy for make dist-docs target only and passed as enviroment variable
MAN_DEPS to the script dist-docs. The files will be copied by script
dist-docs
into $abs_distdir for generating PDF only.
Changes made in V2:
- Filter out .eps files from manpages when make manpage-check target This
prevents manpage-check to perform checks on .eps files
Makefile.am | 5 ++--
build-aux/dist-docs | 8 +-
ovsdb/automake.mk| 2 +-
ovsdb/dot2pic| 80
ovsdb/ovsdb-doc | 5 +---
ovsdb/ovsdb-dot.in | 7 +++--
vswitchd/automake.mk | 20 +++--
vtep/automake.mk | 20 +++--
8 files changed, 40 insertions(+), 107 deletions(-)
delete mode 100755 ovsdb/dot2pic
diff --git a/Makefile.am b/Makefile.am
index 3e5e0b2..5fdd6ec 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -119,6 +119,7 @@ dist_scripts_DATA =
INSTALL_DATA_LOCAL =
UNINSTALL_LOCAL =
man_MANS =
+man_DEPS =
MAN_FRAGMENTS =
MAN_ROOTS =
noinst_DATA =
@@ -346,8 +347,8 @@ if LINUX_ENABLED
cd datapath/linux && $(MAKE) modules_install
endif
-dist-docs:
- VERSION=$(VERSION) $(srcdir)/build-aux/dist-docs $(srcdir) $(docs)
+dist-docs: $(man_DEPS)
+ VERSION=$(VERSION) MAN_DEPS="$(man_DEPS)" $(srcdir)/build-aux/dist-docs
$(srcdir) $(docs)
.PHONY: dist-docs
include m4/automake.mk
diff --git a/build-aux/dist-docs b/build-aux/dist-docs
index 5857c1c..2b31fac 100755
--- a/build-aux/dist-docs
+++ b/build-aux/dist-docs
@@ -48,6 +48,12 @@ make install-man mandir="$abs_distdir"/man
(cd $distdir && mv `find man -type f` . && rm -rf man)
manpages=`cd $distdir && echo *`
+# Install manpage dependencies
+for mandep in $MAN_DEPS; do
+cp "$mandep" "$abs_distdir"
+done
+
+
# Start writing index.html.
exec 3>$distdir/index.html
cat >&3 < $manpage.pdf
+ groff -man -Tps $manpage | ps2pdf - > $manpage.pdf
man -l -Tutf8 $manpage | sed 's/.//g' > $manpage.txt
(echo ''
man -l -Tutf8 $manpage | sed '
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index a66974a..0c3a94c 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -99,7 +99,7 @@ EXTRA_DIST += ovsdb/ovsdb-doc
OVSDB_DOC = $(run_python) $(srcdir)/ovsdb/ovsdb-doc
# ovsdb-dot
-EXTRA_DIST += ovsdb/ovsdb-dot.in ovsdb/dot2pic
+EXTRA_DIST += ovsdb/ovsdb-dot.in
noinst_SCRIPTS += ovsdb/ovsdb-dot
DISTCLEANFILES += ovsdb/ovsdb-dot
OVSDB_DOT = $(run_python) $(srcdir)/ovsdb/ovsdb-dot.in
diff --git a/ovsdb/dot2pic b/ovsdb/dot2pic
deleted file mode 100755
index d682be5..000
--- a/ovsdb/dot2pic
+++ /dev/null
@@ -1,80 +0,0 @@
-#! /usr/bin/perl
-
-# Copyright (c) 2009, 2010, 2011, 2013 Nicira, Inc.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at:
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-use strict;
-use warnings;
-
-use Getopt::Long;
-
-my $font_scale = 0;
-GetOptions("f=i" => \$font_scale) || exit 1;
-
-my ($scale) = 1;
-printf ".ps %+d\n", -$font_scale if $font_scale;
-print ".PS\n";
-print "linethick = 1;\n";
-while (<>) {
-if (/^graph/) {
-(undef, $scale) = split;
-} elsif (/^node/) {
-my (undef, $name, $x, $y, $width, $height, $label, $style, $shape,
$color, $fillcolor) = split;
-$x *= $scale;
-$y *= $scale;
-$width *= $scale;
-$height *= $scale;
-print "linethick = ", ($style eq 'bold' ? 0.5 : 1.0), ";\n";
-print "box at $x,$y wid $width height $height \"$name\"\n";
-if ($style eq 'bold') {
-my $inset = 2.0 / 72.0;
-$width -= $inset * 2;
-$height -= $inset * 2;
-
