On Thu, Feb 18, 2016 at 8:54 AM, David Wragg wrote:
> Tom Herbert writes:
>> Please implement like in ip_tunnel_change_mtu (or better yet call it),
>> that is the precedent for tunnels.
>
> I've made geneve_change_mtu follow ip_tunnel_change_mtu in v2.
>
> If it
On Tue, Feb 16, 2016 at 4:33 AM, David Wragg wrote:
> Jesse Gross writes:
>> On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert wrote:
>>> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
>>>> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
>>>>
On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross wrote:
> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg wrote:
>> Tom Herbert writes:
>>> The correct thing to do is determine the maximum amount of
>>> encapsulation overhead that can ever be set in a packet and use f
On Tue, Feb 9, 2016 at 5:47 PM, David Wragg wrote:
> Allow the MTU of geneve devices to be set to large values, in order to
> exploit underlying networks with larger frame sizes.
>
> GENEVE does not have a fixed encapsulation overhead (an openvswitch
> rule can add variable length options), so the
On Wed, Mar 4, 2015 at 9:00 PM, David Miller wrote:
> From: John Fastabend
> Date: Wed, 04 Mar 2015 17:54:54 -0800
>
>> I think a set operation _is_ necessary for OVS and other
>> applications that run in user space.
>
> It's necessary for the kernel to internally manage the chip
> flow resources
On Wed, Mar 4, 2015 at 11:07 AM, John Fastabend
wrote:
> On 03/04/2015 08:45 AM, Tom Herbert wrote:
>>
>> Hi Simon, a few comments inline.
>>
>> On Tue, Mar 3, 2015 at 5:18 PM, Simon Horman
>> wrote:
>>>
>>> [ CCed netdev as although this
Hi Simon, a few comments inline.
On Tue, Mar 3, 2015 at 5:18 PM, Simon Horman wrote:
> [ CCed netdev as although this is primarily about Open vSwitch userspace
> I believe there are some interested parties not on the Open vSwitch
> dev mailing list ]
>
> Hi,
>
> The purpose of this email is t
> +struct vxlan_metadata {
> + __be32 vni;
> + u32 gbp;
Should this be __be32 also and use ntohl/htonl when setting to/from skb->mark?
> +};
> +
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/lis
On Wed, Jan 14, 2015 at 6:55 PM, Thomas Graf wrote:
> On 01/15/15 at 01:28am, Thomas Graf wrote:
>> What exactly is the problem of having a distinct bitmap used by
>> extensions? It is the least error prone method because it's clear that
>> all extensions must match and we don't have to maintain a
On Wed, Jan 14, 2015 at 4:23 PM, Thomas Graf wrote:
> On 01/14/15 at 04:18pm, Tom Herbert wrote:
>> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> > index 99df0d7..06f7196 100644
>> > --- a/drivers/net/vxlan.c
>> > +++ b/drivers/net/vxlan.c
&g
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 99df0d7..06f7196 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -126,6 +126,7 @@ struct vxlan_dev {
> __u8 tos; /* TOS override */
> __u8 ttl;
> u32
On Tue, Jan 13, 2015 at 3:32 AM, Thomas Graf wrote:
> On 01/12/15 at 06:28pm, Tom Herbert wrote:
>> On Mon, Jan 12, 2015 at 5:03 PM, Thomas Graf wrote:
>> >>
>> >> Creating a level of indirection for extensions seems overly
>> >> complicated to m
On Mon, Jan 12, 2015 at 5:03 PM, Thomas Graf wrote:
> On 01/12/15 at 10:14am, Tom Herbert wrote:
>> > diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>> > index f7d0d2d..9f07bf5 100644
>> > --- a/include/uapi/linux/if_link.h
>>
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index f7d0d2d..9f07bf5 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -370,10 +370,18 @@ enum {
> IFLA_VXLAN_UDP_CSUM,
> IFLA_VXLAN_UDP_ZERO_CSUM6_TX,
> IFLA_V
On Wed, Jan 7, 2015 at 4:14 PM, Thomas Graf wrote:
> On 01/07/15 at 04:02pm, Tom Herbert wrote:
>> Do you know how could GPE work with GBP they want to use the same bits
>> in header for data? Seems like these are mutually exclusive
>> extensions. RCO should be fine with ei
On Wed, Jan 7, 2015 at 3:24 PM, Thomas Graf wrote:
> On 01/07/15 at 02:45pm, Jesse Gross wrote:
>> My concern is that having multiple (and potentially overlapping)
>> extensions is going to make the VXLAN code very messy and hard to
>> follow. I think there's already quite a big of complexity ther
On Wed, Jan 7, 2015 at 8:21 AM, Thomas Graf wrote:
> On 01/07/15 at 08:05am, Tom Herbert wrote:
>> Associating a sixteen bit field with security is worrisome, especially
>> considering that VXLAN provides no verification for any header fields
>> and doesn't even advocate
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> 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 a
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> The VXLAN receive code is currently conservative in what it accepts and
> will reject any frame that uses any of the reserved VXLAN protocol fields.
> The VXLAN draft specifies that "reserved fields MUST be set to zero on
> transmit and ignored
> SKB_GSO_UDP_TUNNEL_CSUM was the right way
> to start splitting overloaded and messy semantics of
> UDP_TUNNEL. I'm still not sure whether you've intended
> it for both rx and tx, since to support tunnel_csum on rx,
> parsing of encap is needed, whereas tx is so much simpler.
> Unless you're assum
On Mon, Sep 22, 2014 at 6:54 PM, Alexei Starovoitov
wrote:
> On Mon, Sep 22, 2014 at 8:10 AM, Tom Herbert wrote:
>> On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
>>> On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
>>>> I think HW should not be limi
On Mon, Sep 22, 2014 at 3:53 PM, Thomas Graf wrote:
> On 09/22/14 at 03:40pm, Tom Herbert wrote:
>> On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
>> > What makes stateful offload interesting to me is that the final
>> > desintation of a packet is known at RX
On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
> On 09/22/14 at 08:10am, Tom Herbert wrote:
>> Thomas, can you (or someone else) quantify what the host case is. I
>> suppose there may be merit in using a switch on NIC for kernel bypass
>> scenarios, but I'
On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
> On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
>> I think HW should not be limited by SW abstractions whether
>> these abstractions are called flows, n-tuples, bridge or else.
>> Really looking forward to see "device reporting the headers as
On Thu, Aug 21, 2014 at 9:41 AM, Ben Hutchings wrote:
> On Thu, 2014-08-21 at 18:18 +0200, Jiri Pirko wrote:
>> The goal of this is to provide a possibility to suport various switch
>> chips. Drivers should implement relevant ndos to do so. Now there is a
>> couple of ndos defines:
>> - for gettin
Signed-off-by: Tom Herbert
---
NEWS|1 +
datapath/actions.c | 16
datapath/flow_netlink.c | 15 +--
include/linux/openvswitch.h | 12 ++--
lib/odp-execute.c |2 +-
lib/odp-util.c |2
This is a reformatted patch to fix problem reported to me by Andy with the
patch format.
Tom Herbert (1):
V3 Add Support for 802.1qad (qinq) Allows TPID of 0x88a8
NEWS|1 +
datapath/actions.c | 16
datapath/flow_netlink.c | 15
I am going to try to come up with a patch for 802.1ad/ah.
--Tom
> On Mar 20, 2014, at 12:19 PM, Ben Pfaff wrote:
>
>> On Thu, Mar 20, 2014 at 12:20:17PM +0530, Deba Prasad Das wrote:
>> This is regarding the VLAN QinQ (802.1AD ) support in OpenvSwitch .
>> We are planning to work on VLAN QinQ
On Tue, Dec 10, 2013 at 11:36 AM, David Miller wrote:
> From: Jesse Gross
> Date: Tue, 10 Dec 2013 11:28:08 -0800
>
>> I think this is definitely a good optimization to do given that so
>> much of the work that OVS does is hashing. However, isn't there a
>> library where there would be a more app
> At an implementation level, the goal is definitely to share as much
> code as possible. Some of that was obviously done to support this
> patch and I'm sure there are more areas where it could be taken
> further.
>
> At a more conceptual level we've explored this path a number of times
> and it'
> This patch adds ipv6 set action functionality. It allows to change
> traffic class, flow label, hop-limit, ipv6 source and destination
> address fields.
>
I have to wonder about these patches and the underlying design
direction. Aren't these sort of things and more already implemented
by IPtable
31 matches
Mail list logo
