On Fri, Jul 5, 2019 at 9:08 AM Taehee Yoo wrote:
>
> When a vport is deleted, the maximum headroom size would be changed.
> If the vport which has the largest headroom is deleted,
> the new max_headroom would be set.
> But, if the new headroom size is equal to the old headroom size,
> updating rou
On Thu, Aug 1, 2019 at 2:14 PM Yifeng Sun wrote:
>
> Currently in function ovs_dp_process_packet(), return values of
> ovs_execute_actions() are silently discarded. This patch prints out
> an error message when error happens so as to provide helpful hints
> for debugging.
>
> Signed-off-by: Yifeng
On Sun, Aug 4, 2019 at 7:56 PM Yifeng Sun wrote:
>
> Currently in function ovs_dp_process_packet(), return values of
> ovs_execute_actions() are silently discarded. This patch prints out
> an debug message when error happens so as to provide helpful hints
> for debugging.
> ---
> v1->v2: Fixed acc
On Wed, Aug 7, 2019 at 5:08 AM Paul Blakey wrote:
>
> Offloaded OvS datapath rules are translated one to one to tc rules,
> for example the following simplified OvS rule:
>
> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk)
> actions:ct(),recirc(2)
>
> Will be translated to the followin
On Sun, Aug 11, 2019 at 3:46 AM Paul Blakey wrote:
>
>
> On 8/8/2019 11:53 PM, Pravin Shelar wrote:
> > On Wed, Aug 7, 2019 at 5:08 AM Paul Blakey wrote:
> >> Offloaded OvS datapath rules are translated one to one to tc rules,
> >> for example
Hi Harald,
On Sat, Jan 9, 2021 at 11:02 PM Pravin B Shelar wrote:
>
> Following patch add support for flow based tunneling API
> to send and recv GTP tunnel packet over tunnel metadata API.
> This would allow this device integration with OVS or eBPF using
> flow based tunneling APIs.
>
> Signed-o
On Sun, Jan 17, 2021 at 5:46 AM Jonas Bonn wrote:
>
> Hi Pravin,
>
> Again, this patch is too big and contains too many disparate changes to
> allow for easy review. Please break this up into a series of logical
> changes for easier review.
>
> On 10/01/2021 08:00, Pravin B Shelar wrote:
> > Foll
On Sun, Jan 17, 2021 at 5:25 AM Jonas Bonn wrote:
>
> Hi Jakub,
>
> On 17/01/2021 01:46, Jakub Kicinski wrote:
> > On Sat, 9 Jan 2021 23:00:21 -0800 Pravin B Shelar wrote:
> >> Following patch add support for flow based tunneling API
> >> to send and recv GTP tunnel packet over tunnel metadata AP
On Sun, Jan 17, 2021 at 7:31 AM Harald Welte wrote:
>
> Hi Jonas, Jakub and others,
>
> On Sun, Jan 17, 2021 at 02:23:52PM +0100, Jonas Bonn wrote:
> > This patch hasn't received any ACK's from either the maintainers or anyone
> > else providing review. The following issues remain unaddressed aft
On Fri, Dec 11, 2020 at 6:15 AM Jonas Bonn wrote:
>
> Hi Pravin,
>
> On 11/12/2020 07:56, Pravin B Shelar wrote:
> > Following patch add support for flow based tunneling API
> > to send and recv GTP tunnel packet over tunnel metadata API.
> > This would allow this device integration with OVS or eB
On Fri, Dec 11, 2020 at 4:28 AM Jonas Bonn wrote:
>
> Signed-off-by: Jonas Bonn
> ---
> drivers/net/gtp.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
> index 236ebbcb37bf..7bbeec173113 100644
> --- a/drivers/net/gtp.c
> ++
On Fri, Dec 11, 2020 at 4:29 AM Jonas Bonn wrote:
>
> All GTP traffic is currently sent from the same source port. This makes
> everything look like one big flow which is difficult to balance across
> network resources.
>
> From 3GPP TS 29.281:
> "...the UDP Source Port or the Flow Label field...
On Fri, Dec 11, 2020 at 4:29 AM Jonas Bonn wrote:
>
> This patch adds support for handling IPv6. Both the GTP tunnel and the
> tunneled packets may be IPv6; as they constitute independent streams,
> both v4-over-v6 and v6-over-v4 are supported, as well.
>
> This patch includes only the driver fun
On Sat, Dec 12, 2020 at 2:11 PM Jakub Kicinski wrote:
>
> On Fri, 11 Dec 2020 20:40:17 -0800 Pravin B Shelar wrote:
> > Following patch add support for flow based tunneling API
> > to send and recv GTP tunnel packet over tunnel metadata API.
> > This would allow this device integration with OVS or
On Fri, Dec 11, 2020 at 11:50 PM Jonas Bonn wrote:
>
>
>
> On 12/12/2020 06:31, Pravin Shelar wrote:
> > On Fri, Dec 11, 2020 at 4:28 AM Jonas Bonn wrote:
> >>
> >> Signed-off-by: Jonas Bonn
> >> ---
> >> drivers/net/gtp.c | 8 +
On Sat, Dec 12, 2020 at 11:56 PM Jonas Bonn wrote:
>
> Hi Pravin,
>
> I've been thinking a bit about this and find it more and more
> interesting. Could you post a bit of information about the ip-route
> changes you'll make in order to support GTP LWT encapsulation? Could
> you provide an exampl
On Mon, Dec 14, 2020 at 12:29 AM Jonas Bonn wrote:
>
> Hi Pravin,
>
> On 13/12/2020 20:32, Pravin Shelar wrote:
> > On Sat, Dec 12, 2020 at 11:56 PM Jonas Bonn wrote:
> >>
> >> Hi Pravin,
> >>
> >> I've been thinking a bit about this an
On Thu, Nov 19, 2020 at 1:04 AM Eelco Chaudron wrote:
>
> Currently, the openvswitch module is not accepting the correctly formated
> netlink message for the TTL decrement action. For both setting and getting
> the dec_ttl action, the actions should be nested in the
> OVS_DEC_TTL_ATTR_ACTION attri
On Sat, Jan 23, 2021 at 12:06 PM Jonas Bonn wrote:
>
> This series begins by reverting the recently added patch adding support
> for GTP with lightweight tunnels. That patch was added without getting
> any ACK from the maintainers and has several issues, as discussed on the
> mailing list.
>
> In
On Sun, Jan 24, 2021 at 6:22 AM Jonas Bonn wrote:
>
> Hi Pravin,
>
> So, this whole GTP metadata thing has me a bit confused.
>
> You've defined a metadata structure like this:
>
> struct gtpu_metadata {
> __u8ver;
> __u8flags;
> __u8type;
> };
>
> Here ver i
On Mon, Jan 25, 2021 at 9:52 AM Harald Welte wrote:
>
> Hi Jonas,
>
> On Sun, Jan 24, 2021 at 03:21:21PM +0100, Jonas Bonn wrote:
> > struct gtpu_metadata {
> > __u8ver;
> > __u8flags;
> > __u8type;
> > };
> >
> > Here ver is the version of the metadata structu
On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn wrote:
>
> Hi Pravin,
>
> On 28/01/2021 22:29, Pravin Shelar wrote:
> > On Sun, Jan 24, 2021 at 6:22 AM Jonas Bonn wrote:
> >>
> >> Hi Pravin,
> >>
> >> So, this whole GTP metadata thing has
On Sat, Jan 30, 2021 at 10:44 AM Jakub Kicinski wrote:
>
> On Fri, 29 Jan 2021 22:59:06 -0800 Pravin Shelar wrote:
> > On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn wrote:
> > > On 28/01/2021 22:29, Pravin Shelar wrote:
> > > > Receive path: LWT extracts tun
On Mon, Feb 1, 2021 at 9:24 PM Jonas Bonn wrote:
>
> Hi Jakub,
>
> On 01/02/2021 21:44, Jakub Kicinski wrote:
> > On Sat, 30 Jan 2021 12:05:40 -0800 Pravin Shelar wrote:
> >> On Sat, Jan 30, 2021 at 10:44 AM Jakub Kicinski wrote:
> >>> On Fri, 29 Jan
On Tue, Feb 2, 2021 at 12:03 AM Jonas Bonn wrote:
>
>
>
> On 02/02/2021 07:56, Pravin Shelar wrote:
> > On Mon, Feb 1, 2021 at 9:24 PM Jonas Bonn wrote:
> >>
> >> Hi Jakub,
> >>
> >> On 01/02/2021 21:44, Jakub Kicinski wrote:
> &
On Mon, Feb 1, 2021 at 10:53 PM Jonas Bonn wrote:
>
> There's ongoing work in this driver to provide support for IPv6, GRO,
> GSO, and "collect metadata" mode operation. In order to facilitate this
> work going forward, this short series accumulates already ACK:ed patches
> that are ready for the
On Sat, Feb 6, 2021 at 10:06 AM Jonas Bonn wrote:
>
> Hi Pravin et al;
>
> TL;DR: we don't need to introduce an entire collect_md mode to the
> driver; we just need to tweak what we've got so that metadata is
> "always" added on RX and respected on TX; make the userspace socket
> optional and dum
On Mon, Apr 30, 2018 at 2:28 PM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, an
On Mon, Apr 30, 2018 at 2:28 PM, Yi-Hung Wei wrote:
> Define netlink messages and attributes to support user kernel
> communication that uses the conntrack limit feature.
>
> Signed-off-by: Yi-Hung Wei
> ---
> include/uapi/linux/openvswitch.h | 62
>
> 1
On Mon, Apr 23, 2018 at 6:39 AM, David Miller wrote:
> From: Yi-Hung Wei
> Date: Tue, 17 Apr 2018 17:30:27 -0700
>
>> Currently, nf_conntrack_max is used to limit the maximum number of
>> conntrack entries in the conntrack table for every network namespace.
>> For the VMs and containers that resi
On Tue, Apr 17, 2018 at 5:30 PM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, an
On Mon, Apr 23, 2018 at 2:19 PM, Yi-Hung Wei wrote:
> On Mon, Apr 23, 2018 at 1:10 PM, Pravin Shelar wrote:
>> On Mon, Apr 23, 2018 at 6:39 AM, David Miller wrote:
>>> From: Yi-Hung Wei
>>> Date: Tue, 17 Apr 2018 17:30:27 -0700
>>>
>>>> Currentl
On Wed, Apr 25, 2018 at 2:51 PM, Yi-Hung Wei wrote:
>>> +#ifIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
>>> +#define OVS_CT_LIMIT_UNLIMITED 0
>>> +#define OVS_CT_LIMIT_DEFAULT OVS_CT_LIMIT_UNLIMITED
>>> +#define CT_LIMIT_HASH_BUCKETS 512
>>> +
>> Can you use static key when the limit is not set.
>>
On Mon, Mar 26, 2018 at 8:08 AM, Eric Dumazet wrote:
> skb mac header is not necessarily set at the time skb_network_protocol()
> is called. Use skb->data instead.
>
> BUG: KASAN: slab-out-of-bounds in skb_network_protocol+0x46b/0x4b0
> net/core/dev.c:2739
> Read of size 2 at addr 8801b3097a0
On Thu, Jun 27, 2019 at 6:37 AM John Hurley wrote:
>
> Skbs may have their checksum value populated by HW. If this is a checksum
> calculated over the entire packet then the CHECKSUM_COMPLETE field is
> marked. Changes to the data pointer on the skb throughout the network
> stack still try to main
I was bit busy for last couple of days. I will finish review by EOD today.
Thanks,
Pravin.
On Mon, Jul 8, 2019 at 4:22 PM Gregory Rose wrote:
>
>
>
> On 7/8/2019 4:18 PM, Gregory Rose wrote:
> > On 7/8/2019 4:08 PM, David Miller wrote:
> >> From: Taehee Yoo
> >> Date: Sat, 6 Jul 2019 01:08:09
ith
> sampled-packet upcall to userspace")
> Cc: Neil McKee
> Signed-off-by: Liping Zhang
> ---
> V2: move actions_attrlen into ovs_skb_cb, which will make codes more
> clean, suggested by Pravin Shelar.
>
> net/openvswitch/actions.c | 2 ++
> net/openvswi
On Tue, Aug 15, 2017 at 6:44 PM, Liping Zhang wrote:
> 2017-08-16 7:35 GMT+08:00 Pravin Shelar :
> [...]
>>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
>>> index e4610676299b..f849ef52853f 100644
>>> --- a/net/openvswitch/actions.c
&g
On Tue, Aug 15, 2017 at 10:30 PM, Liping Zhang wrote:
> From: Liping Zhang
>
> For sw_flow_actions, the actions_len only represents the kernel part's
> size, and when we dump the actions to the userspace, we will do the
> convertions, so it's true size may become bigger than the actions_len.
>
>
On Tue, Aug 13, 2019 at 1:29 AM Paul Blakey wrote:
>
>
> On 8/12/2019 7:18 PM, Pravin Shelar wrote:
> > On Sun, Aug 11, 2019 at 3:46 AM Paul Blakey wrote:
> >>
> >> On 8/8/2019 11:53 PM, Pravin Shelar wrote:
> >>> On Wed, Aug 7, 2019 at 5:08 AM Paul
On Mon, Aug 19, 2019 at 10:42 AM Marcelo Ricardo Leitner
wrote:
>
> On Sun, Aug 18, 2019 at 07:00:59PM +0300, Paul Blakey wrote:
> > What do you guys say about the following diff on top of the last one?
> > Use static key, and also have OVS_DP_CMD_SET command probe/enable the
> > feature.
> >
> >
On Sun, Aug 18, 2019 at 9:01 AM Paul Blakey wrote:
>
> What do you guys say about the following diff on top of the last one?
> Use static key, and also have OVS_DP_CMD_SET command probe/enable the feature.
>
> This will allow userspace to probe the feature, and selectivly enable it via
> the
> OV
On Thu, Aug 22, 2019 at 1:28 PM Yi-Hung Wei wrote:
>
> This patch addresses a conntrack cache issue with timeout policy.
> Currently, we do not check if the timeout extension is set properly in the
> cached conntrack entry. Thus, after packet recirculate from conntrack
> action, the timeout polic
On Wed, Aug 21, 2019 at 5:27 PM Yi-Hung Wei wrote:
>
> Fixes: 06bd2bdf19d2 ("openvswitch: Add timeout support to ct action")
> Signed-off-by: Yi-Hung Wei
> ---
> net/openvswitch/conntrack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/conntrack.c b/net
On Fri, Aug 23, 2019 at 9:40 AM Yi-Hung Wei wrote:
>
> On Thu, Aug 22, 2019 at 11:51 PM Pravin Shelar wrote:
> >
> > On Thu, Aug 22, 2019 at 1:28 PM Yi-Hung Wei wrote:
> > >
> > > This patch addresses a conntrack cache issue with timeout policy.
> > &
On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit wrote:
>
> When IP fragments are reassembled before being sent to conntrack, the
> key from the last fragment is used. Unless there are reordering
> issues, the last fragment received will not contain the L4 ports, so the
> key for the reassembled dat
On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit wrote:
>
> Only the first fragment in a datagram contains the L4 headers. When the
> Open vSwitch module parses a packet, it always sets the IP protocol
> field in the key, but can only set the L4 fields on the first fragment.
> The original behavior
On Sun, Aug 25, 2019 at 9:54 AM Pravin Shelar wrote:
>
> On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit wrote:
> >
> > When IP fragments are reassembled before being sent to conntrack, the
> > key from the last fragment is used. Unless there are reordering
> > issu
On Mon, Aug 26, 2019 at 1:46 PM Greg Rose wrote:
>
> When IP fragments are reassembled before being sent to conntrack, the
> key from the last fragment is used. Unless there are reordering
> issues, the last fragment received will not contain the L4 ports, so the
> key for the reassembled datagra
On Tue, Aug 27, 2019 at 7:58 AM Greg Rose wrote:
>
> From: Justin Pettit
>
> Only the first fragment in a datagram contains the L4 headers. When the
> Open vSwitch module parses a packet, it always sets the IP protocol
> field in the key, but can only set the L4 fields on the first fragment.
> T
On Tue, Aug 27, 2019 at 7:58 AM Greg Rose wrote:
>
> When IP fragments are reassembled before being sent to conntrack, the
> key from the last fragment is used. Unless there are reordering
> issues, the last fragment received will not contain the L4 ports, so the
> key for the reassembled datagra
as is, that is the default
> timeout for the connection will be automatically applied.
>
> Example usage:
> $ nfct timeout add timeout_1 inet tcp syn_sent 100 established 200
> $ ovs-ofctl add-flow br0 in_port=1,ip,tcp,action=ct(commit,timeout=timeout_1)
>
> CC: Pravin
On Thu, Mar 21, 2019 at 3:34 AM wrote:
>
> From: wenxu
>
> There is currently no support for the multicasti/broadcst aspects
> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
> And the packet can forward thr
On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote:
>
> On 2019/3/23 下午3:50, Pravin Shelar wrote:
>
> On Thu, Mar 21, 2019 at 3:34 AM wrote:
>
> From: wenxu
>
> There is currently no support for the multicasti/broadcst aspects
> of VXLAN in ovs. In the datapath flow the tun_
On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote:
>
> On 2019/3/24 上午5:39, Pravin Shelar wrote:
> > On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote:
> >> On 2019/3/23 下午3:50, Pravin Shelar wrote:
> >>
> >> On Thu, Mar 21, 2019 at 3:34 AM wrote:
> >>
&
On Sun, Mar 24, 2019 at 6:24 PM wenxu wrote:
>
> On 2019/3/25 上午2:46, Pravin Shelar wrote:
> > On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote:
> >> On 2019/3/24 上午5:39, Pravin Shelar wrote:
> >>> On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote:
> >>&
On Sat, Mar 23, 2019 at 4:03 AM wrote:
>
> From: wenxu
>
> There is currently no support for the multicast/broadcast aspects
> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
> And the packet can forward thr
On Sun, Mar 24, 2019 at 11:47 AM wrote:
>
> From: Numan Siddique
>
> This patch adds a new action - 'check_pkt_len' which checks the
> packet length and executes a set of actions if the packet
> length is greater than the specified length or executes
> another set of actions if the packet length
On Mon, Mar 25, 2019 at 8:46 PM wrote:
>
> From: wenxu
>
> There is currently no support for the multicast/broadcast aspects
> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
> And the packet can forward thr
On Mon, Mar 25, 2019 at 5:44 PM wrote:
>
> From: Numan Siddique
>
> This patch adds a new action - 'check_pkt_len' which checks the
> packet length and executes a set of actions if the packet
> length is greater than the specified length or executes
> another set of actions if the packet length i
al change.
> It would be useful for other users (i.e. OVS) that utilizes the
> finer-grain conntrack timeout feature.
>
> CC: Pablo Neira Ayuso
> CC: Pravin Shelar
> Signed-off-by: Yi-Hung Wei
> ---
> v1-> v2: Export nf_ct_set_timeout().
> v2-> v3: Fix build i
On Wed, Oct 4, 2017 at 5:03 PM, William Tu wrote:
> Add erspan netlink interface for OVS.
>
> Signed-off-by: William Tu
> Cc: Pravin B Shelar
> ---
> v1->v2: remove unnecessary compat code.
Looks good to me.
On Fri, Oct 6, 2017 at 9:44 AM, Eric Garver wrote:
> This adds a ct_clear action for clearing conntrack state. ct_clear is
> currently implemented in OVS userspace, but is not backed by an action
> in the kernel datapath. This is useful for flows that may modify a
> packet tuple after a ct lookup
On Tue, Oct 10, 2017 at 1:54 PM, Eric Garver wrote:
> This adds a ct_clear action for clearing conntrack state. ct_clear is
> currently implemented in OVS userspace, but is not backed by an action
> in the kernel datapath. This is useful for flows that may modify a
> packet tuple after a ct lookup
On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote:
> This patch series is the first attempt to add openvswitch
> meter support. We have previously experimented with adding
> metering support in nftables. However 1) It was not clear
> how to expose a named nftables object cleanly, and 2)
> the logic
On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote:
> OVS kernel datapath so far does not support Openflow meter action.
> This is the first stab at adding kernel datapath meter support.
> This implementation supports only drop band type.
>
> Signed-off-by: Andy Zhou
> ---
> net/openvswitch/Makefi
On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote:
> Implements OVS kernel meter action support.
>
> Signed-off-by: Andy Zhou
> ---
> include/uapi/linux/openvswitch.h | 1 +
> net/openvswitch/actions.c| 12
> net/openvswitch/datapath.h | 1 +
> net/openvswitch/flow_ne
On Mon, Oct 16, 2017 at 12:05 AM, Andy Zhou wrote:
> On Fri, Oct 13, 2017 at 5:12 PM, Pravin Shelar wrote:
>> On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote:
>>> OVS kernel datapath so far does not support Openflow meter action.
>>> This is the first stab at a
On Thu, Jun 28, 2018 at 8:20 AM, Yifeng Sun wrote:
> Add 'clone' action to kernel datapath by using existing functions.
> When actions within clone don't modify the current flow, the flow
> key is not cloned before executing clone actions.
>
> This is a follow up patch for this incomplete work:
>
On Mon, Jul 2, 2018 at 8:18 AM, Yifeng Sun wrote:
> Add 'clone' action to kernel datapath by using existing functions.
> When actions within clone don't modify the current flow, the flow
> key is not cloned before executing clone actions.
>
> This is a follow up patch for this incomplete work:
> h
On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce wrote:
> From: Stefano Brivio
>
> Open vSwitch sends to userspace all received packets that have
> no associated flow (thus doing an "upcall"). Then the userspace
> program creates a new flow and determines the actions to apply
> based on its configura
On Thu, Mar 8, 2018 at 6:08 PM, zhangliping wrote:
> From: zhangliping
>
> Max delat_t should be the full_bucket/rate instead of the full_bucket.
> Also report EINVAL if the rate is zero.
>
> Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
> Cc: Andy Zhou
> Signed-off-by: zhanglipi
On Tue, Mar 6, 2018 at 5:56 PM, William Tu wrote:
> When sending a packet to a tunnel device, the dev's hard_header_len
> could be larger than the skb->len in function packet_length().
> In the case of ip6gretap/erspan, hard_header_len = LL_MAX_HEADER + t_hlen,
> which is around 180, and an ARP pa
On Wed, Mar 7, 2018 at 3:38 PM, William Tu wrote:
> When sending a packet to a tunnel device, the dev's hard_header_len
> could be larger than the skb->len in function packet_length().
> In the case of ip6gretap/erspan, hard_header_len = LL_MAX_HEADER + t_hlen,
> which is around 180, and an ARP pa
On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi wrote:
> On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
>> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
>> > After push_nsh, the packet won't be recirculated to flow pipeline, so
>> > key->eth.type must be set explicitly here, but for po
On Wed, Oct 4, 2017 at 5:02 AM, William Tu wrote:
> Add type II erspan vport implementation. Since erspan protocol is
> on top of the GRE header, the implementation is extended from the
> existing gre implementation.
>
> Signed-off-by: William Tu
> Cc: Pravin B Shelar
Why are you adding ERSPAN
On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote:
>
> Function queue_userspace_packet() defined in net/openvswitch/datapath.c calls
> nla_nest_start() to allocate memory for struct nlattr which is dereferenced
> immediately. As nla_nest_start() may return NULL on failure, this code piece
> may
On Tue, Aug 21, 2018 at 4:38 PM David Miller wrote:
>
> From: Pravin Shelar
> Date: Tue, 21 Aug 2018 15:38:28 -0700
>
> > On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote:
> >>
> >> Function queue_userspace_packet() defined in net/openvswitch/datapath.c
>
On Tue, Sep 4, 2018 at 3:37 PM Yi-Hung Wei wrote:
>
> Currently, OVS only parses the IP protocol number for the first
> IPv6 fragment, but sets the IP protocol number for the later fragments
> to be NEXTHDF_FRAGMENT. This patch tries to derive the IP protocol
> number for the IPV6 later frags so
On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk wrote:
> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
> included in the L3 length. For example, a short IPv4 packet may have
> up to 6 bytes of padding following the IP payload when received on an
> Ethernet device. In the normal
On Wed, Dec 27, 2017 at 10:33 AM, Joe Perches wrote:
> On Wed, 2017-12-27 at 10:25 -0800, Ben Pfaff wrote:
>> On Wed, Dec 27, 2017 at 04:22:55PM +0100, Julia Lawall wrote:
>> > The email address pshe...@nicira.com listed for Pravin Shelar in
>> > MAINTAINERS (OPENVSWIT
On Tue, Jan 2, 2018 at 11:36 AM, David Miller wrote:
> From: Pravin Shelar
> Date: Thu, 28 Dec 2017 15:47:39 -0800
>
>> Thanks Joe for the patch. But it is corrupted. I will send updated patch
>> soon.
>
> I'm still waiting for this, just FYI :)
I sent the patch.
Thanks.
On Fri, Dec 22, 2017 at 4:39 PM, Ed Swierk wrote:
> On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar wrote:
>> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk
>> wrote:
>>> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
>>> included in the L3
On Thu, Jan 4, 2018 at 10:38 AM, David Miller wrote:
> From: Pravin B Shelar
> Date: Tue, 2 Jan 2018 20:14:42 -0800
>
>> Signed-off-by: Pravin Shelar
>
> Applied, but please take Joe's feedback into consideration.
I was bit busy so could not send update soon. I am p
On Wed, Jan 3, 2018 at 7:49 PM, Ed Swierk wrote:
> On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar wrote:
>> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk
>> wrote:
>>> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
>>> included in the L3
On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk wrote:
> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk
> wrote:
>> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar wrote:
>>> OVS already pull all required headers in skb linear data, so no need
>>> to redo all of it. only che
On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk wrote:
>
>
> On Jan 5, 2018 22:17, "Pravin Shelar" wrote:
>
> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk
> wrote:
>> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk
>> wrote:
>>> On Thu, Jan 4, 2018 at 7:3
On Fri, Jan 5, 2018 at 2:29 PM, William Tu wrote:
> The patch adds support for configuring the erspan version II
> fields for openvswitch.
>
The patch looks good, But it could change userspace API for
OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS, how are we going to handle
compatibility?
> Signed-off-by: Will
On Sat, Jan 6, 2018 at 10:57 AM, Pravin Shelar wrote:
> On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk wrote:
>>
>>
>> On Jan 5, 2018 22:17, "Pravin Shelar" wrote:
>>
>> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk
>> wrote:
>>> On Fri, Jan 5
On Tue, Jan 9, 2018 at 7:17 AM, William Tu wrote:
> On Mon, Jan 8, 2018 at 4:03 PM, Pravin Shelar wrote:
>> On Fri, Jan 5, 2018 at 2:29 PM, William Tu wrote:
>>> The patch adds support for configuring the erspan version II
>>> fields for openvswitch.
>>>
&
On Mon, Jan 8, 2018 at 7:02 PM, Ed Swierk wrote:
> On 1/6/18 10:57, Pravin Shelar wrote:
>> On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk
>> wrote:
>>>
>>>
>>> On Jan 5, 2018 22:17, "Pravin Shelar" wrote:
>>>
>>> On Fri, Jan 5,
On Fri, Jan 12, 2018 at 12:27 AM, Jiri Benc wrote:
> On Thu, 11 Jan 2018 08:34:14 -0800, William Tu wrote:
>> I'd also prefer reverting ceaa001a170e since it's more clean but I
>> also hope to have this feature in 4.15.
>> How long does reverting take? Am I only able to submit the new patch
>> aft
supporting only one field. Thus, this
> patch reverts it and later patch will redo it using nested attr.
>
> Signed-off-by: William Tu
> Cc: Jiri Benc
> Cc: Pravin Shelar
Acked-by: Pravin B Shelar
On Wed, May 23, 2018 at 10:13 AM, David Miller wrote:
> From: Yi-Hung Wei
> Date: Mon, 21 May 2018 17:16:03 -0700
>
>> v3->v4:
>> - Addresses comments from Parvin that include simplify netlink API,
>> and remove unncessary RCU lockings.
>> - Rebases to master.
>
> Pravin, please review.
On Mon, May 21, 2018 at 5:16 PM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, an
On Thu, May 24, 2018 at 5:56 PM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, an
On Thu, May 24, 2018 at 5:56 PM, Yi-Hung Wei wrote:
> Define netlink messages and attributes to support user kernel
> communication that uses the conntrack limit feature.
>
> Signed-off-by: Yi-Hung Wei
Acked-by: Pravin B Shelar
Thanks.
On Mon, Oct 7, 2019 at 9:41 PM Martin Varghese
wrote:
>
> From: Martin Varghese
>
> The openvswitch was supporting a MPLS label depth of 1 in the ingress
> direction though the userspace OVS supports a max depth of 3 labels.
> This change enables openvswitch module to support a max depth of
> 3 l
On Wed, Oct 9, 2019 at 9:31 PM Martin Varghese
wrote:
>
> On Wed, Oct 09, 2019 at 08:29:51AM -0700, Pravin Shelar wrote:
> > On Mon, Oct 7, 2019 at 9:41 PM Martin Varghese
> > wrote:
> > >
> > > From: Martin Varghese
> > >
> > > The ope
On Thu, Oct 10, 2019 at 8:34 PM Martin Varghese
wrote:
>
> On Wed, Oct 09, 2019 at 08:29:51AM -0700, Pravin Shelar wrote:
> > On Mon, Oct 7, 2019 at 9:41 PM Martin Varghese
> > wrote:
> > >
> > > From: Martin Varghese
> > >
> > > The ope
1 - 100 of 570 matches
Mail list logo
