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 D821AA0524; Sun, 11 Apr 2021 06:13:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 63E6F4068A; Sun, 11 Apr 2021 06:13:02 +0200 (CEST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by mails.dpdk.org (Postfix) with ESMTP id C4D414014E for ; Sun, 11 Apr 2021 06:13:00 +0200 (CEST) Received: by mail-qk1-f171.google.com with SMTP id i9so9997727qka.2 for ; Sat, 10 Apr 2021 21:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q74dI1citgZpd26HB9JZZX9cKgwwkBuxeNVDWph85J4=; b=HyE6IZuw2isXjrbv+Uwa/L2zLdusAts1uGz8VJ2KW9f1vAjyfNI7hNmQOhEnaQINXO 7SI3Mj774TIekM4Zo/HFTlVZuGtEP8Sq6ELgt7f8luwT8SPIovcfXg16UB5rG+dtdcOF r7P3rPSb/6Q6xBoddfdupgppa9fePaCosnSTQ= 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=Q74dI1citgZpd26HB9JZZX9cKgwwkBuxeNVDWph85J4=; b=kzbY7BoN4hOmPJgozIYCR1mk+fQNf7MUgvirVAp2R3JOIMG7ZLatIXWEIsQszHDzDP k+lY4lLQOmD0ITc1cqarZ/2tLJRTDhSMCIcYAwxjInsaWW9ePEP61k91zfMUz6AEMQm0 PWzozn937iqpC9RNSceSVPS/Wh6tsHr6m7Bgpxt8xTIVi6s5ggnD9bWaLNTxy5uNyCse 83cL/dNvZ5NLQqjZeQBmOO4qHAOHvmSYZZ9TAGUUpJw03drfibGnnHv4AbYx2BVDn3cO AHWDEWW79Sv/gcwuT+jKJop3Qb1YfYw4m6Xjf1Txm92Tlw9wp5S1G2ng6x7l8p0ambhT l1yQ== X-Gm-Message-State: AOAM5321f+bSkxTCY/cUel6bcmyl8RQekDSQhUUGE4IugEFI49KvPwLw imqciVMp41eWtZj0WyMyZxDzFuCxiHSntYgWipbvxw== X-Google-Smtp-Source: ABdhPJwKGGx8EXtEUkS+NpjywmVrERUNoxLy/mlIrSLxJLPeWAhCJqmXQJLQ8vdyluZ+5YekgJqYeyZXayHSD6xIb7M= X-Received: by 2002:a37:7985:: with SMTP id u127mr21384710qkc.333.1618114379965; Sat, 10 Apr 2021 21:12:59 -0700 (PDT) MIME-Version: 1.0 References: <1617645874-105139-1-git-send-email-orika@nvidia.com> In-Reply-To: From: Ajit Khaparde Date: Sat, 10 Apr 2021 21:12:43 -0700 Message-ID: To: Jerin Jacob Cc: Ori Kam , Andrew Rybchenko , Ferruh Yigit , NBU-Contact-Thomas Monjalon , dpdk-dev , Jerin Jacob , Olivier Matz , Slava Ovsiienko Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d86db605bfaa9c8f" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --000000000000d86db605bfaa9c8f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 8, 2021 at 12:44 AM Jerin Jacob wrote: > > 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. I think this is more reasonable and simpler. Especially when I read the discussion further in the thread between Andrew and Ori. > > > > > > > > > > > > > > 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 --000000000000d86db605bfaa9c8f--