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; ma
gt; packets when common GTP headers are in place, it seems better to revert
> it and rethink things a bit before inclusion.
>
Acked-by: Pravin B Shelar
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 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 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 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 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 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;
>
changes that would have had to be reverted in the process
> of realigning the patch series, things got ugly pretty quickly. The end
> result would not have been pretty.
>
> So the result of this is that Pravin's patch is now mostly still in
> place. I've reworked some small bit
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 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 GT
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:0
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 A
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-off-by: Pravin B Shelar
---
v4-v5:
- coding style changes
v3-v4:
- add check for
Following patch add support for LWT 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-off-by: Pravin B Shelar
---
v3-v4:
- add check for non-zero dst port
v2-v3
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-off-by: Pravin B Shelar
---
v3-v4:
- add check for non-zero dst port
v2-v3
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 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 encapsulat
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-off-by: Pravin B Shelar
---
v2-v3:
- Fixed coding style
- changed IFLA_GTP_FD1
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 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 dev
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 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: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
> ++
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-off-by: Pravin B Shelar
---
Fixed according to comments from Jonas Bonn
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
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-off-by: Pravin B Shelar
---
drivers/net/gtp.c | 541
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
t; argument of table_instance_flow_free.
>
> To avoid a bug when deleting flows in the future, add
> WARN_ON in flush flows function.
>
> Cc: Pravin B Shelar
> Signed-off-by: Tonghao Zhang
Looks good.
Acked-by: Pravin B Shelar
; [1] -
> https://github.com/openvswitch/ovs/commit/acd051f1761569205827dc9b037e15568a8d59f8
> Cc: Pravin B Shelar
> Signed-off-by: Tonghao Zhang
This patch looks good. But its fixing memory leak, I guess the patch
that removed dependedcy on keep_flows is in net-next. so we are good.
Acked-by: Pravin B Shelar
On Mon, Aug 24, 2020 at 12:37 AM wrote:
>
> From: Tonghao Zhang
>
> Not change the logic, just improve coding style.
>
> Cc: Pravin B Shelar
> Signed-off-by: Tonghao Zhang
Acked-by: Pravin B Shelar
On Tue, Aug 25, 2020 at 9:37 AM David Miller wrote:
>
> From: xiangxia.m@gmail.com
> Date: Tue, 25 Aug 2020 13:06:33 +0800
>
> > From: Tonghao Zhang
> >
> > This series patches are not bug fix, just improve codes.
>
> Pravin, please review this patch seri
len, rem = nla_len(attr);
> > > bool clone_flow_key;
> > >
> > > /* The first netlink attribute in 'attr' is always
> > > @@ -1180,7 +1181,8 @@ static int execute_check_pkt_len(struct datapath
> > > *dp, struct sk_buff *skb,
>
On Fri, Jun 19, 2020 at 4:48 AM Lorenzo Bianconi wrote:
>
> ovs connection tracking module performs de-fragmentation on incoming
> fragmented traffic. Take info account if traffic has been de-fragmented
> in execute_check_pkt_len action otherwise we will perform the wrong
> nested action consideri
xidongwang
Looks good.
Acked-by: Pravin B Shelar
On Tue, Oct 22, 2019 at 8:29 AM Martin Varghese
wrote:
>
> On Tue, Oct 22, 2019 at 12:03:49AM -0700, Pravin Shelar wrote:
> > On Sun, Oct 20, 2019 at 7:12 AM Martin Varghese
> > wrote:
> > >
> > > From: Martin Varghese
> > >
> > > The ope
On Sun, Oct 20, 2019 at 7:12 AM 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
On Sun, Oct 20, 2019 at 10:02 PM Tonghao Zhang wrote:
>
> On Sat, Oct 19, 2019 at 2:12 AM Pravin Shelar wrote:
> >
> > On Thu, Oct 17, 2019 at 8:16 PM Tonghao Zhang
> > wrote:
> > >
> > > On Fri, Oct 18, 2019 at 6:38 AM Pravin Shelar wrote:
>
On Sun, Oct 13, 2019 at 3:22 PM Guillaume Nault wrote:
>
> On Sun, Oct 13, 2019 at 12:09:43PM -0700, Pravin Shelar wrote:
> > On Thu, Oct 10, 2019 at 12:07 PM Guillaume Nault wrote:
> > >
> > > In rtnl_net_notifyid(), we certainly can't pass a null GFP flag t
On Thu, Oct 17, 2019 at 8:16 PM Tonghao Zhang wrote:
>
> On Fri, Oct 18, 2019 at 6:38 AM Pravin Shelar wrote:
> >
> > On Wed, Oct 16, 2019 at 5:50 AM wrote:
> > >
> > > From: Tonghao Zhang
> > >
> > > When we destroy the flow tables whic
On Wed, Oct 16, 2019 at 5:50 AM wrote:
>
> From: Tonghao Zhang
>
> When we destroy the flow tables which may contain the flow_mask,
> so release the flow mask struct.
>
> Signed-off-by: Tonghao Zhang
> Tested-by: Greg Rose
> ---
> net/openvswitch/flow_table.c | 14 +-
> 1 file chan
On Tue, Oct 15, 2019 at 8:05 PM Martin Varghese
wrote:
>
> On Tue, Oct 15, 2019 at 12:03:35AM -0700, Pravin Shelar wrote:
> > On Mon, Oct 14, 2019 at 9:06 AM Martin Varghese
> > wrote:
> > >
> > > On Sat, Oct 12, 2019 at 01:08:26PM -0700, Pravin Shelar wrote:
On Mon, Oct 14, 2019 at 9:06 AM Martin Varghese
wrote:
>
> On Sat, Oct 12, 2019 at 01:08:26PM -0700, Pravin Shelar wrote:
> > 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 Fri, Oct 11, 2019 at 7:05 AM wrote:
>
> From: Tonghao Zhang
>
> The full looking up on flow table traverses all mask array.
> If mask-array is too large, the number of invalid flow-mask
> increase, performance will be drop.
>
> This patch optimizes mask-array operation:
>
> * Inserting, insert
On Thu, Oct 10, 2019 at 12:07 PM Guillaume Nault wrote:
>
> In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
> rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
> but there are a few paths calling rtnl_net_notifyid() from atomic
> context or from RCU critical
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
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 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 Sun, Sep 29, 2019 at 7:09 PM wrote:
>
> From: Tonghao Zhang
>
> The most case *index < ma->max, we add likely for performance.
>
> Signed-off-by: Tonghao Zhang
> ---
> net/openvswitch/flow_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/flow_t
On Sun, Sep 29, 2019 at 7:09 PM wrote:
>
> From: Tonghao Zhang
>
> The full looking up on flow table traverses all mask array.
> If mask-array is too large, the number of invalid flow-mask
> increase, performance will be drop.
>
> This patch optimizes mask-array operation:
>
> * Inserting, insert
On Sun, Sep 29, 2019 at 7:09 PM wrote:
>
> From: Tonghao Zhang
>
> Port the codes to linux upstream and with little changes.
>
> Pravin B Shelar, says:
> | mask caches index of mask in mask_list. On packet recv OVS
> | need to traverse mask-list to get cached mask. There
l 6e237d099fac "(netlink: Relax attr validation
> for fixed length types)", this bug is exposed by the below
> warning
>
> [ 57.215841] netlink: 'ovs-vswitchd': attribute type 5 has an
> invalid length.
>
> Signed-off-by: Li RongQing
Acked-by: Pravin B Shelar
Thanks,
Pravin.
On Sat, Sep 21, 2019 at 8:48 PM Hillf Danton wrote:
>
> On Sun, 9 Sep 2019 11:14 from Pravin Shelar
>
> >
>
> > There is already patch a patch to fix this memory leak.
>
> > https://patchwork.ozlabs.org/patch/1144316/
>
> > Can you or Hillf post it on ne
On Fri, Sep 20, 2019 at 5:06 PM Daniel Borkmann wrote:
>
> On 9/21/19 12:56 AM, Jakub Kicinski wrote:
> [...]
> >> I thought idea of stuffing things into skb extensions are only justified if
> >> it's not enabled by default for everyone. :(
> >>
> >> [0]
> >> https://lore.kernel.org/netdev/ca
On Sat, Sep 21, 2019 at 8:07 AM wrote:
>
> From: Tonghao Zhang
>
> If we register a net device which name is not valid
> (dev_get_valid_name), register_netdevice will return err
> codes and will not run dev->priv_destructor. The memory
> will leak. This patch adds check in ovs_vport_free and
> se
OvS datapath.
>
> Signed-off-by: Paul Blakey
> Signed-off-by: Vlad Buslov
> Acked-by: Jiri Pirko
Looks good to me.
Acked-by: Pravin B Shelar
Thanks,
Pravin.
l4'. Then we add a another new function
> ovs_flow_key_update_l3l4() and export it so that it is accessible by
> handle_fragments() for conntrack packet reassembly.
>
> Co-authored by: Justin Pettit
> Signed-off-by: Greg Rose
>
Looks good to me.
Acked-by: Pravin B Shelar
Thanks,
Pravin.
;
> Signed-off-by: Justin Pettit
Acked-by: Pravin B Shelar
Thanks,
Pravin.
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 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
}
> if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
> key->ip.frag = OVS_FRAG_TYPE_FIRST;
>
Looks good to me.
Acked-by: Pravin B Shelar
Thanks,
Pravin.
> }
>
> + /* The key extracted from the fragment that completed this datagram
> +* likely didn't have an L4 header, so regenerate it. */
> + ovs_flow_key_update(skb, key);
> +
> key->ip.frag = OVS_FRAG_TYPE_NONE;
> skb_cle
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.
> > &
per");
> + OVS_NLERR(log, "Invalid conntrack timeout");
> return -EINVAL;
> }
> break;
Acked-by: Pravin B Shelar
Thanks,
Pravin.
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 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 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 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 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
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
--
> v1->v2: Fixed according to Pravin's review.
>
Looks good.
Acked-by: Pravin B Shelar
Thanks,
Pravin.
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
ize,
> updating routine is unnecessary.
>
> Signed-off-by: Taehee Yoo
Sorry for late reply. This patch looks good to me too.
I am curious about reason to avoid adjustment to headroom. why are you
trying to avoid unnecessary changes to headroom.
Thanks,
Pravin.
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
> >
d basic MPLS support to kernel")
> Fixes: bc7cc5999fd3 ("openvswitch: update checksum in {push,pop}_mpls")
> Signed-off-by: John Hurley
> Reviewed-by: Jakub Kicinski
> Reviewed-by: Simon Horman
> ---
Thanks for fixing it.
Acked-by: Pravin B Shelar
> net/openvsw
src_vni 1000 vni 1000 self
>
> Signed-off-by: wenxu
> ---
> include/uapi/linux/openvswitch.h | 1 +
> net/openvswitch/flow_netlink.c | 46
> +++-
> 2 files changed, 37 insertions(+), 10 deletions(-)
>
Looks good.
Acked-by: Pravin B Shelar
Thanks,
Pravin.
On Tue, Mar 26, 2019 at 8:16 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
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
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 Shela
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
rted-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
> Suggested-by: Ben Pfaff
> Signed-off-by: Numan Siddique
> CC: Gregory Rose
> CC: Pravin B Shelar
> ---
> v1 -> v2
> -
>* Addressed the review comments.
> - Rem
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
rted-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
> Suggested-by: Ben Pfaff
> Signed-off-by: Numan Siddique
> CC: Gregory Rose
> CC: Pravin B Shelar
> ---
This looks pretty good to me. I have couple of comments inl
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 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 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 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 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
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
rewrite fields with the same values as matched"),
> with no functional change.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Roi Dayan
Thanks.
Acked-by: Pravin B Shelar
functional change.
> >>>
> >>> Signed-off-by: Eli Britstein
> >>> Reviewed-by: Roi Dayan
> >> I agree with Pravin, this need a much better commit message.
> >>
> >> Maybe even better to submit this alongside whatever is supposed
> &
On Thu, Jan 24, 2019 at 1:47 AM Eli Britstein wrote:
>
> Declare ovs key structures using macros to enable retrieving fields
> information, with no functional change.
>
I am not sure why is this done. Can you explain what are u trying to solve here?
> Signed-off-by: Eli Britstein
> Reviewed-by:
}
>
> - if (!nz || !is_all_zero(nla_data(nla), expected_len)) {
> + if (!nz || !is_all_zero(nla_data(nla), nla_len(nla))) {
> attrs |= 1 << type;
> a[type] = nla;
> }
Good Catch.
Acked-by: Pravin B Shelar
On Wed, Sep 26, 2018 at 2:58 AM Stefano Brivio wrote:
>
> Hi Pravin,
>
> On Wed, 15 Aug 2018 00:19:39 -0700
> Pravin Shelar wrote:
>
> > I understand fairness has cost, but we need to find right balance
> > between performance and fairness. Current fairness sche
On Wed, Sep 26, 2018 at 11:40 AM Yifeng Sun wrote:
>
> This patch fixes the bug that all datapath and vport ops are returning
> wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
>
> Signed-off-by: Yifeng Sun
I am surprised this was not found earlier.
Acked-by:
later frags so that we can match that.
>
> Signed-off-by: Yi-Hung Wei
Acked-by: Pravin B Shelar
Thanks.
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 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
Hi Stefano
On Tue, Aug 7, 2018 at 6:31 AM, Stefano Brivio wrote:
> Hi Pravin,
>
> On Tue, 31 Jul 2018 16:12:03 -0700
> Pravin Shelar wrote:
>
>> Rather than reducing number of thread down to 1, we could find better
>> number of FDs per port.
>> How about this s
On Fri, Aug 10, 2018 at 10:19 AM, 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
1 - 100 of 722 matches
Mail list logo
