On Thu, 20 Oct 2016 21:22:21 -0700, Pravin Shelar wrote:
> The eth pop substracts ETH_HLEN but here the length is set. I think it
> should be consistent with respect to eth-pop.
Agreed. Will use skb_reset_mac_len in both, that better reflects what's
going on.
Thanks,
Jiri
__
On Thu, 20 Oct 2016 21:19:14 -0700, Pravin Shelar wrote:
> On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc wrote:
> > @@ -609,8 +597,10 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb,
> > struct genl_info *info)
> >
> > err = ovs_flow_key_extract_userspace
From: Lorand Jakab
These actions will allow L2->L3 and L3->L2 switching, and are supposed
to be added to flows installed in the datapath transparently by
ovs-vswitchd.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
v12 [Simon Horman]
* Rebase
* P
Horman
Signed-off-by: Jiri Benc
---
v12
* Rebase
v11
* Update for new kernel implementation that uses ARPHRD_NONE devices
* Omit match_base_layer from struct tun_port_in, it is not necessary any more
* Correct OVS_KEY_ATTR_NEXT_BASE_LAYER handling in odp_flow_key_from_flow__()
and
n Horman
Signed-off-by: Jiri Benc
---
v12+
* Correct ATTR_ETHERTYPE/ETHERNET logic in odp_key_to_pkt_metadata()
v12 [Simon Horman]
* No change
v11 [Simon Horman]
* Fold in previously separate patches
"userspace: add layer 3 support to packet metadata"
"userspace: extend
This is a rebase of Simon's submission from July on top of the current
master. It is not intended to be applied yet but to help testing of the
kernel part.
The rebase was straightforward, the differences are:
* Accomodated changes made by aff49b8c66be ("meta-flow: Clean up masking
with prerequi
On Tue, 18 Oct 2016 22:11:21 -0700, Pravin Shelar wrote:
> I have not finished the review yet, but most of patches looks good to
> me. Can you send userspace patches against latest master so that I can
> try the patches with tunnel setup?
Will do in a few minutes.
Thanks for the review,
Jiri
__
On Tue, 18 Oct 2016 22:14:06 -0700, Pravin Shelar wrote:
> This is OVS tunnel compatibility code. We are not suppose to add new
> features to compat code. Just provide a way to configure such device
> over rtnl.
Makes sense. Please consider this a test-only patch for now. I won't
include it in v13
On Tue, 18 Oct 2016 22:13:45 -0700, Pravin Shelar wrote:
> On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc wrote:
> > - skb_reset_network_header(skb);
> > + skb->protocol = parse_ethertype(skb);
>
> I am not sure about changing skb->protocol here.
>
Some symbols exported to other modules are really used only by
openvswitch.ko. Remove the exports.
Tested by loading all 4 openvswitch modules, nothing breaks.
Signed-off-by: Jiri Benc
---
v2: ovs_vport_deferred_free is completely removed by the first patch
---
net/openvswitch/datapath.c
Removed unused functions and unnecessary EXPORT_SYMBOLs from openvswitch.
Jiri Benc (2):
openvswitch: remove unused functions
openvswitch: remove unnecessary EXPORT_SYMBOLs
net/openvswitch/datapath.c | 2 --
net/openvswitch/vport-netdev.c | 1 -
net/openvswitch/vport.c| 17
ovs_vport_deferred_free is not used anywhere. It's the only caller of
free_vport_rcu thus this one can be removed, too.
Signed-off-by: Jiri Benc
---
new in v2
---
net/openvswitch/vport.c | 16
net/openvswitch/vport.h | 1 -
2 files changed, 17 deletions(-)
diff --git
On Tue, 18 Oct 2016 12:48:33 -0700, Pravin Shelar wrote:
> ovs_vport_deferred_free() is not used anywhere. can you remove it?
Good point. Will do.
Jiri
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Many symbols exported to other modules are really used only by
openvswitch.ko. Remove the exports.
Tested by loading all 4 openvswitch modules, nothing breaks.
Signed-off-by: Jiri Benc
---
net/openvswitch/datapath.c | 2 --
net/openvswitch/vport-netdev.c | 1 -
net/openvswitch/vport.c
y: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
include/uapi/linux/openvswitch.h | 15
net/openvswitch/actions.c| 49
net/openvswitch/flow_netlink.c | 18 +++
3 files changed, 82 insertions(+
Allow ARPHRD_NONE interfaces to be added to ovs bridge.
Based on previous versions by Lorand Jakab and Simon Horman.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
net/openvswitch/vport-netdev.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
From: Simon Horman
This allows GRE tunnels to send and receive both
layer 2 packets (packets with an ethernet header) and
layer 3 packets (packets without an ethernet header).
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
v12: removed the non-gre hunks (now part of previous patches
and Simon Horman.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
net/openvswitch/flow_netlink.c | 160 +
1 file changed, 99 insertions(+), 61 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch
cular packet. For example, ARPHRD_NONE tunnels that encapsulate
Ethernet should get at least the Ethernet header.
Signed-off-by: Jiri Benc
---
net/openvswitch/actions.c | 29 +
net/openvswitch/vport.c | 2 +-
net/openvswitch/vport.h | 2 +-
3 files changed, 19 inser
Update Ethernet header only if there is one.
Signed-off-by: Jiri Benc
---
net/openvswitch/actions.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index dc8bb97e2258..064cbcb7b0c5 100644
--- a/net
in place yet.
Based on previous versions by Lorand Jakab and Simon Horman.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
net/openvswitch/datapath.c | 17 ++--
net/openvswitch/flow.c | 101 ++---
net
packet going to L3 interface.
Signed-off-by: Jiri Benc
---
net/openvswitch/actions.c | 3 ++-
net/openvswitch/vport.c | 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 1105c4e29c62..49af167105d3 100644
t, we can just remove all those branches completely.
Signed-off-by: Jiri Benc
---
There are three possible approaches:
(1) The one in this patch.
(2) Use just a one bit flag indicating whether the packet is L3 or Ethernet
(similar to the "is_layer3" bool in v11). The code
sly posted patchset for
Open vSwitch user space works with this submission unmodified.
Jiri Benc (8):
openvswitch: use hard_header_len instead of hardcoded ETH_HLEN
openvswitch: add mac_proto field to the flow key
openvswitch: pass mac_proto to ovs_vport_send
openvswitch: support MPLS push and
Reviving a very old thread, sorry. Simon handed this over to me, I'm
preparing v12.
On Fri, 15 Jul 2016 14:07:37 -0700, pravin shelar wrote:
> I am not sure if you can use only mac_len to detect L3 packet. This
> does not work with MPLS packets, mac_len is used to account MPLS
> headers pushed on
On Sat, 3 Sep 2016 13:30:12 -0400, Eric Garver wrote:
> Would a BUG_ON(!(encap && in_encap)) be better?
Please don't crash the kernel for something that could very well
continue without problems. Use WARN_ON at most.
And if you go that way, WARN_ON_ONCE or rate limiting seems to be even
more appr
On Mon, 8 Aug 2016 17:17:17 +0200, Simon Horman wrote:
> +bool skb_mac_header_present(struct sk_buff *skb)
> +{
> + return skb->dev->type == ARPHRD_ETHER ||
> + (skb->dev->type == ARPHRD_NONE &&
> + skb->protocol == htons(ETH_P_TEB));
> +}
> +EXPORT_SYMBOL(skb_mac_heade
On Mon, 18 Jul 2016 13:50:27 +0900, Simon Horman wrote:
> On Fri, Jul 15, 2016 at 02:07:37PM -0700, pravin shelar wrote:
> > I think we should send L2 header with l2 header pushed on skb. This is
> > what OVS expect. The skb-push should be done for all l2 packets rather
> > than for particular type
On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
> I think history tells us how this will end - similar to IPv4 options,
> implementations that don't implement TLVs will become deployed and
> then when there is a use for them it's no longer possible. Since I
> don't want OVS to have a half im
On Wed, 13 Jul 2016 01:35:50 +0800, Johnson Li wrote:
> To remove dependency for Simon Horman's patch at:
> http://openvswitch.org/pipermail/dev/2016-June/072010.html
> We derived some codes to add the push_eth/pop_eth flow actions
> to enable Ethernet as the encapsulation layer.
The dependency is
On Wed, 13 Jul 2016 01:25:45 +0800, Johnson Li wrote:
> In order to support NSH without depending on Simon's patch, we
> introduced new flow actions push_eth and pop_eth to support the
> Ethernet as a NSH transport.
That doesn't make any sense. Please build this on top of Simon's
patchset.
Jiri
On Thu, 23 Jun 2016 11:04:38 +0900, Simon Horman wrote:
> I think you are right as IIRC the call to skb_reset_mac_header was
> added for this use-case. Its unfortunate that we can't use it in
> internal_dev_xmit() because of loosing track of MPLS as you mentioned
> earlier. But it does seem that se
On Sun, 12 Jun 2016 15:53:50 +0800, Yang, Yi wrote:
> Will use net device after those patches are merged into net-next, It
> seems current net device implementation in net-next doesn't include it,
The current kernel should have everything that's needed for VXLAN-GPE
support.
> do you mean this on
On Sun, 12 Jun 2016 20:53:23 +0800, Yang, Yi wrote:
> On Mon, Jun 06, 2016 at 02:22:58PM -0700, Jesse Gross wrote:
> > However, the changes to vport-vxlan.c are modifying compatibility code
> > that shouldn't be extended further. Instead, just use the existing
> > VXLAN netlink interfaces that have
On Mon, 6 Jun 2016 14:22:58 -0700, Jesse Gross wrote:
> On Sat, Jun 4, 2016 at 6:39 AM, Yi Yang wrote:
> [...]
> > datapath/vport-netdev.c | 3 +-
> > datapath/vport-vxlan.c| 17 ++-
>
> These changes aren't upstream yet. Please do that bef
On Fri, 20 May 2016 18:12:05 +0900, Simon Horman wrote:
> 1. push_eth adds an Ethernet header with all-zero addresses and
>the Ethernet type as determined from skb->protocol which is in
>turn determined by the tunnel header (we have discussed that
>bit before).
>
>In principle it i
On Fri, 20 May 2016 17:16:13 +0900, Simon Horman wrote:
> My understanding is that currently OvS handles access ports using a
> push_vlan action.
When needed (i.e. when the packet goes to a non-access port), yes.
> And that this patch set in conjunction with its
> user-space counterpart should en
On Fri, 20 May 2016 14:29:01 +0900, Simon Horman wrote:
> The second option does seem rather tempting although I'm not sure
> that it actually plays out in the access-port scenario at this time.
We support gre ports to be access ports currently. With conversion to
ipgre, this needs to continue wor
On Wed, 4 May 2016 16:36:31 +0900, Simon Horman wrote:
> + /* Packets from user space for execution only have metadata key
> + * attributes. OVS_KEY_ATTR_PACKET_ETHERTYPE is then used to specify
> + * the starting layer of the packet. Packets with Ethernet headers
> + * have t
On Thu, 12 May 2016 07:46:52 +0900, Simon Horman wrote:
> If we can live with a bogus skb->mac_len value that is sufficient for
> ovs_flow_key_extract.() and set correctly by key_extract() (which happens
> anyway) we could do something like this:
>
> } else if (vport->dev->type == ARPHRD_NON
Looking through the patchset again, this time more deeply. Sorry for
the delay.
On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> +struct ovs_action_push_eth {
> + struct ovs_key_ethernet addresses;
> + __be16 eth_type;
Extra spaces.
> +static int pop_eth(struct sk_buff *skb, s
On Wed, 11 May 2016 12:06:35 +0900, Simon Horman wrote:
> Is this close to what you had in mind?
Yes but see below.
> @@ -739,17 +729,17 @@ int ovs_flow_key_extract(const struct ip_tunnel_info
> *tun_info,
> key->phy.skb_mark = skb->mark;
> ovs_ct_fill_key(skb, key);
> key->ovs
On Wed, 11 May 2016 12:28:14 +0900, Simon Horman wrote:
> I think that at this stage I would prefer to prohibit push_eth() acting
> on a packet which already has an ethernet header. Indeed that is what
> my patch-set already does in its modifications of __ovs_nla_copy_actions().
>
> The reason tha
On Wed, 11 May 2016 10:50:12 +0900, Simon Horman wrote:
> On Tue, May 10, 2016 at 02:01:06PM +0200, Jiri Benc wrote:
> > We have two options here:
> >
> > 1. As for metadata tunnels all the info is in metadata_dst and we
> >don't need the IP/GRE header for
Please do not top post.
On Tue, 10 May 2016 00:16:36 +, Yang, Yi Y wrote:
> I think it is still necessary to keep eth_type in push_eth action, for
> the classifier case, it will push_nsh then push_eth for the original
> frame, this will need to set eth_type to 0x894f by push_eth, otherwise
> p
On Mon, 9 May 2016 17:18:20 +0900, Simon Horman wrote:
> On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc wrote:
> > In addition, we should check whether mac_len > 0 and in such case,
> > change skb->protocol to ETH_P_TEB first (and store that value in the
On Mon, 9 May 2016 17:04:22 +0900, Simon Horman wrote:
> It seems to be caused by the following:
>
> 1. __ipgre_rcv() calls skb_pop_mac_header() which
>sets skb->mac_header to the skb->network_header.
>
> 2. __ipgre_rcv() then calls ip_tunnel_rcv() which calls
>skb_reset_network_header().
On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> +static int push_eth(struct sk_buff *skb, struct sw_flow_key *key,
> + const struct ovs_action_push_eth *ethh)
> +{
> + int err;
> +
> + /* De-accelerate any hardware accelerated VLAN tag added to a previous
> +
On Fri, 6 May 2016 14:57:07 +0900, Simon Horman wrote:
> On Thu, May 05, 2016 at 10:37:08AM -0700, pravin shelar wrote:
> > On transmit side you are using mac_len to detect l3 packet, why not do
> > same while extracting the key?
I agree. The skb should be self-contained, i.e. it should be obvious
On Fri, 6 May 2016 15:54:02 +0900, Simon Horman wrote:
> -int ovs_netdev_send_raw_tun(struct sk_buff *skb)
> -{
> - if (skb->mac_len)
> - skb->protocol = ntohs(ETH_P_TEB);
> + if (dev->type != ARPHRD_ETHER && skb->mac_len) {
> + skb->protocol = htons(ETH_P_TEB);
> +
On Mon, 18 Apr 2016 11:30:43 -0700, Jesse Gross wrote:
> (Even on new kernels I don't know how this would interact
> with OVS tunnel ports that are not of type 'flow'. Would they also use
> the compat code?)
This is a very good point. Although, on the other hand, how much common
are tunnel ports w
On Mon, 18 Apr 2016 06:57:22 -0300, Thadeu Lima de Souza Cascardo wrote:
> I don't see how this address the case when the user adds a vxlan interface
> created by the system. Like:
>
> ip link add vxlan_sys_4789 type vxlan id 10 remote 192.168.123.1 dstport 4789
> ovs-vsctl add-port br0 vxlan_sys_
On Fri, 15 Apr 2016 20:36:51 -0700, Jesse Gross wrote:
> What about using the driver name exposed through ethtool? I believe
> that all of the tunnel and internal devices expose this in a
> consistent way - i.e. a VXLAN device can be queried and get back the
> string "vxlan". Any driver other than
On Fri, 15 Apr 2016 18:30:59 -0300, Thadeu Lima de Souza Cascardo wrote:
> Jiri has suggested that we require users to create the interfaces themselves,
> by
> using whatever method their OS has, and add them as netdev devices. That would
> still require fetching some of the configuration from the
On Thu, 25 Feb 2016 17:32:28 -0800, Jesse Gross wrote:
> The thing that bothers me about this is that it's not really a binary
> split between Ethernet and IP. L2 "obviously" means Ethernet (although
> theoretically there could be other things), but L3 means IPv4, IPv6,
> MPLS, NSH, etc.? That is w
the moment.
> I think this is very closely related and complementary as it also
> depends on sending non-Ethernet frames to OVS. He might have some
> ideas on how to handle this.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
ot cover all cases, though.
ETH_TYPE_ should cover everything - after all, we need to be able to
send the encapsulated packets out.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
which caused a serious
> performance
> drop.
The patch looks good to me. Haven't really reviewed it line by line but
haven't spotted any obvious problem and I think this is good way
forward.
Thanks a lot for doing this!
Jiri
--
Jiri Benc
_
parameter).
- Adding the bool parameter for strict checking to rtnl_link_ops
validate and slave_validate callbacks.
It would mean refactoring of rtnl_newlink.
Or do you have something more generic in mind? Like adding a new
NLM_F_REQUEST_STRICT flag to nlmsghdr to be used instead of
NLM_F_REQUEST
ch
to 4.3 should the need arise.
Signed-off-by: Jiri Benc
---
This is intentionally submitted to net-next. Kernel 4.3 will be fine without
this feature (but despite that, I'd like to keep the two flags separate).
---
include/uapi/linux/openvswitch.h | 12
net/openvswitch/
Add netlink attributes for IPv6 tunnel addresses. This enables IPv6 support
for tunnels.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
v2: Changed description. Rebased tun_proto assignment in ip_tun_from_nlattr
to accomodate changes in the previous patch.
v3: No change
d was added to a hole in sw_flow_key.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
v2: Set the tun_proto mask to 0xff in ip_tun_from_nlattr.
v3: No change.
---
net/openvswitch/flow.c | 4 ++--
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 10 --
shortly. There's no need nor intent to add
a support for this into the vport-vxlan (etc.) compat layer.
---
v3: dropped the last two patches added in v2.
Jiri Benc (2):
openvswitch: add tunnel protocol to sw_flow_key
openvswitch: netlink attributes for IPv6 tunneling
include/uapi/
On Tue, 29 Sep 2015 19:10:54 -0300, Thadeu Lima de Souza Cascardo wrote:
> From: Jiri Benc
>
> ipv6_addr_is_set is going to be used by next patches.
>
> [cascardo: compare with in6addr_any in ipv6_addr_is_set]
It was actually done with the "or" for purpose, it'
On Thu, 1 Oct 2015 22:19:10 -0700, Pravin Shelar wrote:
> On Thu, Oct 1, 2015 at 9:08 AM, Jiri Benc wrote:
> > This is for IPv4 only at this point. Only vxlan is recognized for now.
> >
> > The usage is as follows:
> >
> > ip l a type vxlan metadata dstport 4789
's actually
what I did in v1.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, 1 Oct 2015 17:11:43 -0700, Pravin Shelar wrote:
> On Thu, Oct 1, 2015 at 7:44 AM, Jiri Benc wrote:
> > +static inline void ip_tunnel_key_init(struct ip_tunnel_key *key,
> > + __be32 saddr, __be32 daddr,
> > +
On Thu, 1 Oct 2015 18:08:51 +0200, Jiri Benc wrote:
> This is for IPv4 only at this point. Only vxlan is recognized for now.
>
> The usage is as follows:
>
> ip l a type vxlan metadata dstport 4789
> ovs-vsctl add-port ovsbridge vxlan0
^ should be
eld:2->tun_id,set_field:192.168.1.1->tun_dst,1'
ovs-ofctl add-flow ovs0 'in_port=1,tun_id=2 actions=2'
Note that this depends on iproute2 patches that are not merged yet to create
the metadata based vxlan interface.
Signed-off-by: Jiri Benc
--
d was added to a hole in sw_flow_key.
Signed-off-by: Jiri Benc
---
v2: Set the tun_proto mask to 0xff in ip_tun_from_nlattr.
---
net/openvswitch/flow.c | 4 ++--
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 10 --
net/openvswitch/flow_table.c | 2
For compat tunnel interfaces, reject IPv6 keys.
Also fixes a related thinko in vport-vxlan: upcall->egress_tun_info is not
yet set at the point where it is used, thus the obtained family is
incorrect. As this is IPv4 anyway, just use AF_INET.
Signed-off-by: Jiri Benc
---
New patch in v2 of
Add netlink attributes for IPv6 tunnel addresses. This enables IPv6 support
for tunnels.
Signed-off-by: Jiri Benc
---
v2: Changed description. Rebased tun_proto assignment in ip_tun_from_nlattr
to accomodate changes in the previous patch.
---
include/uapi/linux/openvswitch.h | 2 +
net
shortly. There's no need nor intent to add
a support for this into the vport-vxlan (etc.) compat layer.
Jiri Benc (4):
openvswitch: add tunnel protocol to sw_flow_key
openvswitch: netlink attributes for IPv6 tunneling
ip_tunnels: introduce ip6_tunnel_key_init
openvswitch: IPv6 suppor
We already have ip_tunnel_key_init, this does the same for IPv6. Will be
used also by openvswitch in the next patch.
Signed-off-by: Jiri Benc
---
New patch in v2 of the set.
---
include/net/dst_metadata.h | 18 ++
include/net/ip_tunnels.h | 40
27;t think that fixing the bug should be a prerequisite for
this patchset, the problem is already there and this patchset doesn't
change that.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, 30 Sep 2015 13:25:12 -0700, Jesse Gross wrote:
> On Wed, Sep 30, 2015 at 1:13 PM, Pravin Shelar wrote:
> > On Wed, Sep 30, 2015 at 12:09 AM, Jiri Benc wrote:
> >> On Tue, 29 Sep 2015 13:41:34 -0700, Pravin Shelar wrote:
> >>> We can add rather add TUNNEL_IPV
;m simply not adding more code to the first, legacy interface, which
seems to be the correct thing to do.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, 29 Sep 2015 19:08:44 -0700, Jesse Gross wrote:
> On Tue, Sep 29, 2015 at 10:52 AM, Jiri Benc wrote:
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index 5c030a4d7338..03ba070c3256 100644
> > --- a/net/openvswitch/flow_ne
> That also saves space in flow key.
The field was added to a 2 byte hole in the struct sw_flow_key (leaving
still 1 byte free), thus there's no additional space used.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswit
the kernel, with geneve to follow shortly. There's no need nor intent to add
a support for this into the vport-vxlan compat layer.
Jiri Benc (2):
openvswitch: add tunnel protocol to sw_flow_key
openvswitch: netlink attributes for IPv6 tunneling
include/uapi/linux/openvswitch.h | 2 +
Add netlink attributes for IPv6 tunnel addresses. This enables IPv6 support
for tunnels.
When compat code for tunnel configuration is used, IPv6 tun_info will be
rejected by ovs_tunnel_get_egress_info. As the consequence, only the new way
of tunnel config supports IPv6.
Signed-off-by: Jiri Benc
d was added to a hole in sw_flow_key.
Signed-off-by: Jiri Benc
---
net/openvswitch/flow.c | 4 ++--
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 7 +--
net/openvswitch/flow_table.c | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git
The ifup/ifdown will operate only on configured interfaces, so
> this patch fixes the issue by deleting the interface from the
> database before attempt to configure it.
>
> Signed-off-by: Flavio Leitner
Acked-by: Jiri Benc
--
Jiri Benc
n)))
>
> +struct ovs_tunnel_info
> +{
> + struct ip_tunnel_info *info;
> +};
Why do you keep this structure? It doesn't seem it's useful.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Mon, 1 Jun 2015 15:11:03 -0700, Jesse Gross wrote:
> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
> > diff --git a/include/net/vxlan.h b/include/net/vxlan.h
> > index 0082b5d33d7d..a4ed7241c56a 100644
> > --- a/include/net/vxlan.h
> > +++ b/include/net/vxlan
On Mon, 1 Jun 2015 15:09:54 -0700, Jesse Gross wrote:
> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
> > Other users of IPv6 tunneling (e.g. openvswitch) may not have a net_device
> > that represents the tunnel.
> >
> > Signed-off-by: Jiri Benc
>
> I
On Mon, 1 Jun 2015 15:07:11 -0700, Jesse Gross wrote:
> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
> > diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
> > index b22d45775eb5..ca9ebb9eb0f7 100644
> > --- a/net/openvswitch/vport.h
> > +++ b/net/open
On Mon, 1 Jun 2015 14:40:41 -0700, Jesse Gross wrote:
> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
> > diff --git a/include/uapi/linux/openvswitch.h
> > b/include/uapi/linux/openvswitch.h
> > index 4d26da40b01f..ba7ae3b05308 100644
> > --- a/include/uapi/li
On Mon, 1 Jun 2015 14:22:48 -0700, Jesse Gross wrote:
> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
> > diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> > index 2af6ffbf2f2e..78e96a120120 100644
> > --- a/net/openvswitch/flow.h
> > +++ b/net/ope
the kernel.
Signed-off-by: Jiri Benc
---
v1->v2: Disable LRO unconditionally. If the feature that leaves LRO enabled
is implemented in the future in ovs user space, the conditional disablement
can be implemented in the kernel easily. There won't be any problem even
if such new ovs user spac
that the problem is deeper. I'll look
into it.
Doesn't affect the rest of the set, this is just a bug I encountered
while testing the set.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
ing is netlink. And as this is very
much ovs specific (all other users of dev_disable_lro such as bridging
want to do this unconditionally), ovs netlink is the correct place to
put this to.
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.or
part than the
kernel one, actually. And some decisions I had to make are independent
on the kernel/user space boundary.
Thanks a lot!
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
the kernel.
As there are use cases of openvswitch setup that can keep LRO enabled and
there's a planned feature to optimize such use cases (and stop disabling LRO
unconditionally from the user space daemon), allow the user space to
override this when adding the interface.
Signed-off-by: Jiri
ly need to do #1? (And in that case, what to do
with cross-netns vlans? Use the new netnsid infrastructure and switch
netns while traversing the links?)
Thanks,
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
the problems I outlined in the cover
letter of the other set, though.
Thanks!
Jiri
--
Jiri Benc
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
The flow structure was changed, increase the sequence number. All the
asserts either do not apply or have been resolved by previous patches in
this set.
Signed-off-by: Jiri Benc
---
lib/flow.c | 12 ++--
lib/flow.h | 4 ++--
lib/match.c
There's no route cache for ipv6, thus we cannot consult it when checking for
status change. It means we currently don't know the status of the outgoing
interface, this may be fixed later.
Signed-off-by: Jiri Benc
---
lib/netdev-vport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Note that because there's been no prerequisite on the outer protocol,
we cannot add it now. Instead, treat the ipv4 and ipv6 dst fields in the way
that either both are null, or at most one of them is non-null.
Signed-off-by: Jiri Benc
---
lib/dpif.c | 6 --
lib/flow.c
This is currently not standardized anywhere. Until it is, those fields are
not settable by openflow.
Signed-off-by: Jiri Benc
---
lib/meta-flow.c | 42 ++
lib/meta-flow.h | 35 +++
lib/nx-match.c | 4
3 files changed
1 - 100 of 126 matches
Mail list logo
