From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52]) by dpdk.org (Postfix) with ESMTP id 293C93256 for ; Wed, 21 Jun 2017 01:55:23 +0200 (CEST) Received: by mail-pg0-f52.google.com with SMTP id u62so50095900pgb.3 for ; Tue, 20 Jun 2017 16:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zcrFe7AwIQ9MSOv4xRiOFjuCrCHoA+8VyStHpeDgZao=; b=aDLcsQHwtbY4GYwsvk4sSZ7tks7dhOZXuvI+B5FcpVzS/R8ZGCzUgsAp5T4LKqTB8+ e6QeZ1oEcEz4mW+mURshmHHvCC50Lb2kMYIzG9+RgCy1bnHBMpEB4HDw7HCrpaxMh2e7 dhVDzk5ewXStUXWIgY84PNSZY/hnKyK997ty8dN/OMdaJ5qaSzrfWbKkphm8tUutSpnU h2PZoTYJ9AT8d45x8hjZNK2eTkVTDwh9Kq6cFBgwQ/x9uSfMhYf4uuKRzYUNQbF3bfP1 7ccD06UoJrPFaz+SsOU4V1r5IxlqYzupRmWV3YeavVwqH5EBDzhpBee6W3wSoP5w/1rW XG1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zcrFe7AwIQ9MSOv4xRiOFjuCrCHoA+8VyStHpeDgZao=; b=WMKXnYv2lgBV7cUF9UbcMaljYn5naAxn29cHuflCEdKwLDaDIFbOnfz43HzBpJlc0K PkUvyjFTiyqaIos7r56puLxwxqWttX2eTLwm496LB1ZH31lnfNrvtYuccLMVTz2aZHPj AkboJftpl5dd9TL3YpTOjqFFawJT/AasNU2gqldHNY9sgzG1v84D6Pc4MMO6o9oggcwL Es69E4PHxNBubpG5uJxlghOg2fwtAGkKBE7ypCM426k9zZ6GbyKQsYKklcv43ci5q8yw GZcgnOSQNjSUAwxW1X770SVi/8tGwfMcMmy2qGQATy1vPoJOFoi6B1jIKrQkzVBJX+uT f//A== X-Gm-Message-State: AKS2vOznf73z1AtxtRpZr2pLoZQBmNhadtKylQG+FLTsAZxt/AHhyiTi ZS4d1lGPwcM7ZNaY X-Received: by 10.99.24.66 with SMTP id 2mr34425937pgy.105.1498002922295; Tue, 20 Jun 2017 16:55:22 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id u194sm29759027pgc.2.2017.06.20.16.55.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Jun 2017 16:55:22 -0700 (PDT) Date: Tue, 20 Jun 2017 16:55:15 -0700 From: Stephen Hemminger To: "Tan, Jianfeng" Cc: Jiayu Hu , dev@dpdk.org, konstantin.ananyev@intel.com, yliu@fridaylinux.org, keith.wiles@intel.com, tiwei.bie@intel.com, lei.a.yao@intel.com Message-ID: <20170620165515.1e4387cd@xeon-e3> In-Reply-To: <21e9e28b-ba41-b88d-1f9a-b022b0d2c5ce@intel.com> References: <1496833731-53653-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-3-git-send-email-jiayu.hu@intel.com> <20fd3a2c-9b61-2732-5a34-5acb8fc639a0@intel.com> <20170620032220.GB12728@localhost.localdomain> <21e9e28b-ba41-b88d-1f9a-b022b0d2c5ce@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO 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: Tue, 20 Jun 2017 23:55:23 -0000 On Wed, 21 Jun 2017 07:30:08 +0800 "Tan, Jianfeng" wrote: > >>> To process an incoming packet, we need three steps: > >>> a. check if the packet should be processed. Packets with the following > >>> properties won't be processed: > >>> - packets without data; > >>> - packets with wrong checksums; > >> Why do we care to check this kind of error? Can we just suppose the > >> applications have already dropped the packets with wrong cksum? > > Indeed, if we assume all inputted packets are correct, we can avoid > > checksum checking overhead. But as a library, I think a more flexible > > way is to enable applications to tell GRO API if checksum checking > > is needed. For example, we can add a flag to struct rte_gro_tbl > > and struct rte_gro_param, which indicates if the checksum checking > > is needed. If applications set this flag, reassembly function won't > > check packet checksum. Otherwise, we check the checksum. How do you > > think? > > My opinion is to keep the library focusing on what it does, and make > clear its dependency. This flag thing will differ for different GRO > engines, which makes it a little complicated to me. As long as it is documented behavior. GIGO is fine. IMHO a well designed library does as little as possible and nothing more.