From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f65.google.com (mail-it0-f65.google.com [209.85.214.65]) by dpdk.org (Postfix) with ESMTP id 03B8C1B25A for ; Thu, 21 Dec 2017 14:59:17 +0100 (CET) Received: by mail-it0-f65.google.com with SMTP id r6so10927465itr.3 for ; Thu, 21 Dec 2017 05:59:17 -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=xLcshv7txJYy8zWFRQAJbUugSMa9GDIArzLCi32+4+M=; b=dYFkjN+vySi78fdHfqeojspfX1FyVbpwXU+20PF7YR8StoeUaUD007X7y0hxNOOo29 LyWBNYJR2oHTtU05uIQY9e3V5bWaGA2SVd7WaETGkh2tBoOqgY95ZmqkLfNOnl2lKLos B8FGgDx2LpvNN68EL+XbaTf70dFokRn64w/Zh85dLtMGGRos7BT8AMC6BS1mzdJ3NMtE qy2OkVt0wuXq3vsfqxHX9eHzSNAuTrVsDBl9z/9dKrLc6abqkaJQKhjPW57g7WGhJ/dl oi+SbBYhsFGkulOfXC8nYlhJ3IsPiXLeelyx1Nv96b2e1n+0i57sjOWWTEr0jKAeh6Ck DCPA== 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=xLcshv7txJYy8zWFRQAJbUugSMa9GDIArzLCi32+4+M=; b=H7T12gORK/6RqZdyFUVkFBwYDvL+KIXP9LqlBvjlzukAF0vDJmUOQMYd3/lEz4wdxb zC1DRGXUhOL6Dqj3rcpYSJZQ6VmizW/3jjd9A2Icft0q1sPIM5iBdKsVMwomwOMFU2Rl RJQUPgfqs+aXxcYq5ycYkv7AnY8RBe4VuIBWVEa/QYuPbrplyKBz1LkVaUjs8fnzrMER mHUsq4tfAfU+rq47x2yAOpqT9pJJDOhdQLARHoVX6XOcuWYGjhEAsCM1+AJ5dUDV/LQw 6zRvMp3sxn1MxeqEfcxklDB6hX7Oav/8bxy3r5jUjyVRaJKECfPMFQXkYzDh3ONe0JD8 7LOg== X-Gm-Message-State: AKGB3mIsFrAMYlmVf51JhXL6VM+FEhy87ifj5U9HS3rsmGp8PQM68qBQ TNZeRWIcaJ45Z3OSb5FtM75Os36rL1NN2aQMbnLr2ecZ X-Google-Smtp-Source: ACJfBovVq3Uk4+U6jnsy3K6Um1pnffU2/Jxj9oQEzhoQWzoMNuA5Su9lDyTU6YXxO6AdzPTiL67EUAXu/ED0ZXIQuyA= X-Received: by 10.36.39.8 with SMTP id g8mr13609010ita.42.1513864757209; Thu, 21 Dec 2017 05:59:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.53.2 with HTTP; Thu, 21 Dec 2017 05:59:16 -0800 (PST) In-Reply-To: <1513823719-36066-4-git-send-email-qi.z.zhang@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> From: Alex Rosenbaum Date: Thu, 21 Dec 2017 15:59:16 +0200 Message-ID: To: Qi Zhang Cc: adrien.mazarguil@6wind.com, DPDK , Declan Doherty 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: Thu, 21 Dec 2017 13:59:18 -0000 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... 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? I would prefer to have the aging timer logic in a centralized location, leek the application itself or some DPDK library. instead of having each PMD implement its own software timers. > 3. Register a callback function when a flow is deleted due to timeout. Is the application 'struct rte_flow*' handle really deleted? or the flow was removed from HW, just in-active at this time? Can a flow be re-activated? or does this require a call to rte_flow_destory() and ret_flow_create()? Alex