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 2801CA0524; Fri, 19 Mar 2021 18:03:01 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 970FE140FAA; Fri, 19 Mar 2021 18:03:00 +0100 (CET) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by mails.dpdk.org (Postfix) with ESMTP id 5BAD340143 for ; Fri, 19 Mar 2021 18:02:59 +0100 (CET) Received: by mail-ot1-f46.google.com with SMTP id g8-20020a9d6c480000b02901b65ca2432cso9182263otq.3 for ; Fri, 19 Mar 2021 10:02:59 -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=g7MGKrYcgxE0DtPFDNSWfkAafW3d2wzBa4m4wNGfN48=; b=S9MP64ZpFYV+20HROs2JWuJcNNiWfe1x5sit7Vv8OxZUXEzuu+CVsHKYL/mqvH42uI NPs0jrNhs6AwDH88TxvyPfUdV1BdI12DO98zRhK3hFgXunO54bq8WIcZ49qXAxgDs/dZ vk/rVdokOI4BXgQ8m/d2xHdbhVl1ZhznFpLCg= 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=g7MGKrYcgxE0DtPFDNSWfkAafW3d2wzBa4m4wNGfN48=; b=GDEWy+fwfpi8+NSxEloYXeuH+PLynzJ0+alkbUs9c+CavCg4YfZ8sM84BgyJv9aosI K32pCHMz1QROPd+GKm+bcRDMKUHJqWVQkBnhZBnECkIjuOXiTEaaOsBMjfdbHj5RujBi y0buyuh90M95x/CdxsPX0ENhekzNjLjmZJjCg9hnPTzZh5mMha/G8laTLNESRQhHlgXT EmH0K3KHaKdTN/VTXiyQDgYwDPrXYkW5ccMjqP9dbO/oAT+YWuOxpTf+++h73QczDbfd SDsPJQ3zYKo0CywpZ8L0Rh6PMWtVkoK6WEnoXD34S50IwUn6yoaXaAl99ZRCfD096Gzo j9HA== X-Gm-Message-State: AOAM532HsHqE1VJYgC8/UYheIDzD3ZcJFrLH6YG8D5kpBHA5/WyBozQl GbRtH4ul/cr54EBk2DSIkFEmJ+2O+v7N0tUXNvxXrg== X-Google-Smtp-Source: ABdhPJx/YdqQfZSkmtDCcpp/6EiKF1koA7PtVd3mFbZoqQROjLhwme6znlqhdXwVNewyMGT9tPsfmwxOQH2QaitG3bY= X-Received: by 2002:a9d:6ad9:: with SMTP id m25mr1869918otq.267.1616173378531; Fri, 19 Mar 2021 10:02:58 -0700 (PDT) MIME-Version: 1.0 References: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com> <20210319090653.22b430ea@hermes.local> In-Reply-To: <20210319090653.22b430ea@hermes.local> From: Lance Richardson Date: Fri, 19 Mar 2021 13:02:47 -0400 Message-ID: To: Stephen Hemminger Cc: "Min Hu (Connor)" , "dev@dpdk.org" , Ferruh Yigit , Thomas Monjalon Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000023d67d05bde6b027" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] Questions about keeping CRC 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" --00000000000023d67d05bde6b027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 19, 2021 at 12:07 PM Stephen Hemminger wrote: > > On Fri, 19 Mar 2021 20:13:20 +0800 > "Min Hu (Connor)" wrote: > > > Hi, all, > > DPDK has introduced one offload: DEV_RX_OFFLOAD_KEEP_CRC. It mean= s that > > the device has the ablility of keeping CRC=EF=BC=88four bytes at the en= d of > > packet=EF=BC=89of packet in RX. > > In common scenarios, When one packet enter into NIC device, NIC > > will check the CRC and then strip the CRC=EF=BC=8Cat last send the pack= et into > > the buffer. > > So my question is: > > why the DEV_RX_OFFLOAD_KEEP_CRC is introduced into DPDK? I thin= k that > > when the packet enter into the NIC, the CRC will has no significance to > > APP. Or is there any scenarios that CRC is useful for APP=EF=BC=9F > > Thanks for your reply. > > Your right it doesn't make sense for almost all applications. Maybe an ap= plication > testing for bad NIC hardware might use it. > > It is one of those features introduced in DPDK because "our hardware can = do it, > therefore it ought to be exposed in DPDK API"... The only use case I have seen was in L2 forwarding applications which would receive packets with CRC preserved and then transmit them with an indicatio= n to the NIC that the CRC should not be regenerated. The idea was that if the packet was corrupted anywhere in the system (e.g. by a memory error), it could be detected at the receiver. Of course DPDK doesn't have the notion of transmitting a packet without regenerating the CRC, so that use case doesn't seem to apply here. I think that DEV_RX_OFFLOAD_KEEP_CRC is not likely to be useful, but I would be interested in hearing otherwise. I happen to know of at least on= e PMD that advertises this ability but doesn't actually behave any differentl= y when it is enabled. --00000000000023d67d05bde6b027--