From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7A720A0579; Thu, 8 Apr 2021 09:44:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 247A740698; Thu, 8 Apr 2021 09:44:29 +0200 (CEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 65BA340138 for ; Thu, 8 Apr 2021 09:44:28 +0200 (CEST) Received: by mail-il1-f172.google.com with SMTP id t14so999557ilu.3 for ; Thu, 08 Apr 2021 00:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GFLruFWAril4t49NyrZIYK6faMDua4Dmn2d5MAqBSJE=; b=HNe3t7bCnW4n0hCF7fveeO6i1alyGz82YvuVfkjNHrBo8NX9T7agJtc+Vtsaw5ZW7x H4mbJWceoJGyjnKM8tcHYMHp9Xon0ecyEwKriOnvCItV+3isCZHp/7+4ZxOgehqxGEvU Dh1t/e8dHxNIBWOQjUCHx5NWgsTKJExfLzImQaYgLbUODpf+OeVNrcdsbdYTLs9+C0l6 2RWscrWdP+awMeNsPrYpXvFxkHzA6oOcZg3OBmJTssX6qG1vwvoZf9VQef9CQ/hTGOno FVHKjbSoM4gN3Fdg22irchJYas6jRtzW1sGawg0gJ+V7yMQNxJ5nGSoUGEyeOK5vVuiV MjOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GFLruFWAril4t49NyrZIYK6faMDua4Dmn2d5MAqBSJE=; b=JNPEWKd5BXRXpoHaGQWMGDxaKrA92QfpM8aZcpupUC2zJxK7RphuN/1bpTY8Px1VHt 6DFxLGPrpqB82GLv5iyuYi1JS341HZi607rS9nr7AmDuFDNCdEgSpOZC1zTPF+fezRfF R4pmdeCxtEhOYOQeKsqEpUj3hufYo9N+i83Q66bsVxlnWdP1/E4JT/0xKaiZ5CIkICBD sS6MSSMHfag7C1qo+0wt5vNT/5GrINxxHw0PoKClXEJdx4oX1YbiQuk9+I6c0ngW8W4z HudsH/Ygw4FPTeDSwUn5Nk8o0FJ+MaJ3x4y8wB+AfT/9FipF9AuQcS00Z8QbwuqpFcza x1+Q== X-Gm-Message-State: AOAM531gv9yp9VSgR+jHQwloubRycxtCNp1Up8AmMex/06r7nEhPLjnx meMj8j9Iy7OahSaDK4f4qtuvcT51/7HAK5oaRX0= X-Google-Smtp-Source: ABdhPJwsNWPOrJr/sWmo5idaKFfW8Gjrq9U8GPgKzFggpSB72/q0h48Dabivg1krVx7+/ehBMPOuLYomY2gXh2aSFHY= X-Received: by 2002:a92:c566:: with SMTP id b6mr4852625ilj.162.1617867867756; Thu, 08 Apr 2021 00:44:27 -0700 (PDT) MIME-Version: 1.0 References: <1617645874-105139-1-git-send-email-orika@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Thu, 8 Apr 2021 13:14:11 +0530 Message-ID: To: Ori Kam Cc: Ajit Khaparde , Andrew Rybchenko , Ferruh Yigit , NBU-Contact-Thomas Monjalon , dpdk-dev , Jerin Jacob , Olivier Matz , Slava Ovsiienko Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 8, 2021 at 3:45 AM Ori Kam wrote: > > Hi Jerin, > > > -----Original Message----- > > From: Jerin Jacob > > Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks > > > > On Wed, Apr 7, 2021 at 4:02 PM Ori Kam wrote: > > > > > > Hi Jerin, > > > > Hi Ori, > > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Tuesday, April 6, 2021 10:40 AM > > > > To: Ori Kam > > > > Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks > > > > > > > > On Mon, Apr 5, 2021 at 11:35 PM Ori Kam wrote: > > > > > > > > > > Currently, DPDK application can offload the checksum check, > > > > > and report it in the mbuf. > > > > > > > > > > However, as more and more applications are offloading some or all > > > > > logic and action to the HW, there is a need to check the packet > > > > > integrity so the right decision can be taken. > > > > > > > > > > The application logic can be positive meaning if the packet is > > > > > valid jump / do actions, or negative if packet is not valid > > > > > jump to SW / do actions (like drop) a, and add default flow > > > > > (match all in low priority) that will direct the miss packet > > > > > to the miss path. > > > > > > > > > > Since currenlty rte_flow works in positive way the assumtion is > > > > > that the postive way will be the common way in this case also. > > > > > > > > > > When thinking what is the best API to implement such feature, > > > > > we need to considure the following (in no specific order): > > > > > 1. API breakage. > > > > > 2. Simplicity. > > > > > 3. Performance. > > > > > 4. HW capabilities. > > > > > 5. rte_flow limitation. > > > > > 6. Flexability. > > > > > > > > > > > > Alteast in Marvell HW integrity checks are functions of the Ethdev Rx > > > > queue attribute. > > > > Not sure about other Vendor HW. > > > > > > I'm not sure what do you mean? > > > > What I meant is, What will be the preferred way to configure the feature? > > ie. Is it as ethdev Rx offload or rte_flow? > > > > I think, in order to decide that, we need to know, how most of the > > other HW express this feature? > > > > As I see it both ways could be used, > Maybe even by the same app, > > One flow is to notify the application when it sees the packet > (RX offload) and one is to use as an item to route the packet > when using rte_flow. > > Maybe I'm missing something, on your suggestion how will > application route the packets? Or it will just receive them with flags > on the RX queue? Just receive them with flags on the Rx queue, in order to avoid duplicating features in multiple places. > > > > > > > > This is the idea of the patch, to allow application to route the packet > > > before getting to the Rx, > > > In any case all items support is dependent on HW capabilities. > > > > > > > > > > Best, > Ori