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, 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 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;
> __u8type;
> };
>
> Here ver i
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 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 GTP tunnel packet over tunnel metadata AP
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
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 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 encapsulation? Could
> you provide an exampl
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 device integration with OVS or
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
> ++
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 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 Mon, Aug 24, 2020 at 10:08 PM wrote:
>
> From: Tonghao Zhang
>
> Decrease table->count and ufid_count unconditionally,
> because we only don't use count or ufid_count to count
> when flushing the flows. To simplify the codes, we
> remove the "count" argument of table_instance_flow_free.
>
> To
On Mon, Aug 24, 2020 at 10:08 PM wrote:
>
> From: Tonghao Zhang
>
> keep_flows was introduced by [1], which used as flag to delete flows or not.
> When rehashing or expanding the table instance, we will not flush the flows.
> Now don't use it anymore, remove it.
>
> [1] -
> https://github.com/op
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 series.
>
Sorry for delay. I will have a l
On Mon, Jun 22, 2020 at 5:02 AM Lorenzo Bianconi wrote:
>
> > 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_che
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
On Mon, Jun 15, 2020 at 7:13 PM Xidong Wang wrote:
>
> From: xidongwang
>
> The stack object “zone_limit” has 3 members. In function
> ovs_ct_limit_get_default_limit(), the member "count" is
> not initialized and sent out via “nla_put_nohdr”.
>
> Signed-off-by: xidongwang
Looks good.
Acked-by:
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. Therefore array
> | is better f
On Tue, Sep 24, 2019 at 4:11 AM Li RongQing wrote:
>
> userspace openvswitch patch "(dpif-linux: Implement the API
> functions to allow multiple handler threads read upcall)"
> changes its type from U32 to UNSPEC, but leave the kernel
> unchanged
>
> and after kernel 6e237d099fac "(netlink: Relax
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
On Wed, Sep 4, 2019 at 6:56 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 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
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 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
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 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 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 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 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
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 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 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
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
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
On Wed, Mar 27, 2019 at 9:43 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 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
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
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 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 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
On Sun, Feb 3, 2019 at 1:12 AM Eli Britstein wrote:
>
> Declare ovs key structures using macros as a pre-step towards to
> enable retrieving fields information, as a work done in proposed
> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
> ("odp-util: Do not rewrite fields with
Can you send patch with this information in commit msg?
On Thu, Jan 31, 2019 at 3:32 AM Eli Britstein wrote:
>
> ping
>
> for the using patch, i put below the v1 of it. here is v2:
>
> https://patchwork.ozlabs.org/patch/1023406/
>
>
> On 1/27/2019 8:37 AM, Eli Britstein wrote:
> >
> > On 1/27/20
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:
On Mon, Jan 14, 2019 at 1:17 AM Ross Lagerwall
wrote:
>
> For nested and variable attributes, the expected length of an attribute
> is not known and marked by a negative number. This results in an OOB
> read when the expected length is later used to check if the attribute is
> all zeros. Fix this
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: Pravin B Shelar
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 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
On Tue, Jul 31, 2018 at 12:43 PM, Matteo Croce wrote:
> On Mon, Jul 16, 2018 at 4:54 PM Matteo Croce wrote:
>>
>> On Tue, Jul 10, 2018 at 6:31 PM Pravin Shelar wrote:
>> >
>> > On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce wrote:
>> > > From: Stefan
On Fri, Jul 27, 2018 at 1:03 AM, Li RongQing wrote:
> The size of struct cpumask varies with CONFIG_NR_CPUS, some config
> CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take
> 640 bytes, if there is thousands of flows, it will take lots of
> memory
>
I am fine with removing cpumask
On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger
wrote:
> The call to nla_nest_start when forming packet messages can lead to a NULL
> return so it's possible for attr to become NULL and we can potentially
> get a NULL pointer dereference on attr. Fix this by checking for
> a NULL return.
>
> B
On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger
wrote:
> The call to nla_nest_start in conntrack can lead to a NULL
> return so it's possible for attr to become NULL and we can potentially
> get a NULL pointer dereference on attr. Fix this by checking for
> a NULL return.
>
> Bugzilla: https:/
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 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
1 - 100 of 570 matches
Mail list logo
