From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by dpdk.org (Postfix) with ESMTP id E24D81DBF for ; Fri, 22 Dec 2017 23:26:34 +0100 (CET) Received: by mail-it0-f42.google.com with SMTP id b5so15800140itc.3 for ; Fri, 22 Dec 2017 14:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GK7b1Ta/GU14xstAF7MIdmJBNyiFfiZZLZRtVSNgcUo=; b=Q3fpS9MV4JOgYdv4JAWizhIEz9DCfZYwdG2w63tfZOGC/vh+DYDxsU+LKDp+FdgvE3 4fCNkx83qbTudJqaOyjA26htQ5+I1nwwrK642GqkeXAlSuysQW+4BrXWrOrr8VhUd0Wt ejthbJzoeRh1uj7YvUOj0TwfFjSIRX/Z6rDCzIy21qqxUFYz9KqdepqsOULpxzy2tucq BRJK1rwpj2h/+1CQa5bGDCaliAesh6MN8MPsIuUf8b7mVqdvoNBfxVHneVcFEahQ0V/n 6Nd0d7iAucSDIgn77fTrO8HD2oDb4zkKXDcse3W0n3R8uzOt/ZzHo47E2V2JoTAiwbKI cqyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GK7b1Ta/GU14xstAF7MIdmJBNyiFfiZZLZRtVSNgcUo=; b=qfm36ezJACXjwUUb9ef4OyoTYQTqiGh6P8Aev9j8goPhb9wl2lZKMlu63VsObtFj9s Y4M9kGv07DXcwo1RynKAuNaSz6uWFFyKEGp2A6rZe+E8nPp/zrWUSRReVS+t1yO+ysoO Visg2jeA66Zfqz9ED7bqeKXwrfLC8PfUYSZ2NaPrMA4YGfwh9TUUPgIu6V3M/7kdoELH l4eZsBwHHMTgcqkbhI19zIwOoHTHHP8uVGJkh8+Qe5Yxp+AGU6PjW03mMmfIhUvce89c mknhXqsrXeLR+aflOeHyp9C1bbHjkjZi1qFZY0pZk7FEctbYlTBgY8I7hE2SYdAGHMXs J0Jg== X-Gm-Message-State: AKGB3mJUgYbp6oaLBbSLDd92bjVnTmGw7ZI4LaftozBRqabfgvcP5IVb UvEVVbC0r4G7LXdMSsTIb06gJPzxNOad0MMhtcE= X-Google-Smtp-Source: ACJfBouX9M7ovbtw6aa1yPTKBM9OmeO3+120oIgVvSIPQM27COkqCW+kaE5qz/qIDkDlo7j4XOs0910YidqcMNvrFKk= X-Received: by 10.36.37.138 with SMTP id g132mr21378180itg.72.1513981594181; Fri, 22 Dec 2017 14:26:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.53.2 with HTTP; Fri, 22 Dec 2017 14:26:33 -0800 (PST) In-Reply-To: <039ED4275CED7440929022BC67E7061153124111@SHSMSX103.ccr.corp.intel.com> References: <1513823719-36066-1-git-send-email-qi.z.zhang@intel.com> <1513823719-36066-4-git-send-email-qi.z.zhang@intel.com> <039ED4275CED7440929022BC67E7061153124111@SHSMSX103.ccr.corp.intel.com> From: Alex Rosenbaum Date: Sat, 23 Dec 2017 00:26:33 +0200 Message-ID: To: "Zhang, Qi Z" Cc: "adrien.mazarguil@6wind.com" , DPDK , "Doherty, Declan" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 22:26:35 -0000 On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z wrote: >> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote: >> > Add new APIs to support flow timeout, application is able to 1. Setup >> > the time duration of a flow, the flow is expected to be deleted >> > automatically when timeout. >> >> Can you explain how the application (OVS) is expected to use this API? >> It will help to better understand the motivation here... > > I think the purpose of the APIs is to expose the hardware feature that support > flow auto delete with a timeout. > As I know, for OVS, every flow in flow table will have time duration > A flow be offloaded to hardware is still required to be deleted in specific time, > I think these APIs help OVS to take advantage HW feature and simplify the flow > aging management Are you sure this will allow OVS to 'fire-and-forget' about the rule removal? or will OVS anyway do rule cleanup from application tables? Do you know if OVS flow timers are (or can be) re-armed in different use cases? e.g. extending the timeout duration if traffic is still flowing? >> Are you trying to move the aging timer from application code into the PMD? >> or can your HW remove/disable/inactivate a flow at certain time semantics >> without software context? > > Yes, it for hardware feature. So if the hardware auto removes the hardware steering entry, what software part deletes the rte_flow handle? What software part triggers the application callback? from what context? will locks be required? How do you prevent races between application thread and the context deleting/accessing the rte_flow handle? I mean in cases that application wants to delete the flow before the timeout expires, but actually it is same time hardware deletes it. Alex