From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by dpdk.org (Postfix) with ESMTP id 0715F5A69 for ; Fri, 30 Oct 2015 13:14:59 +0100 (CET) Received: by oies66 with SMTP id s66so57488529oie.1 for ; Fri, 30 Oct 2015 05:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8McJnBYdzN6YGKR1d27uc2yGRo3bKsEZQGKGVyc9SSM=; b=vNG9WGZ2P0xoK0pzdHI232McWR9poJdpVk7wMogw79Q2c4nR+SJsDp57qEAdQcTGeN UJVKmfbRzQEyq4ho2KZIwcPLKZyg4i8EgTmh6Q9yNmX+QxskGZwsoam4sjh/Y0VcwWoT 8R+R+2WQGqd5oJKd+EeYyaE4E6dyoXgpFnvtIRAh7xdWtUlP2730MDGak5sGIxNHouJB /q02dle7u29ivj0aBItgWc0DCEbw2RLYlKsPOpz+99cKst2znFRyV5cO0N8+3UfUWYCe fBQjLthkb0a0sYDCEpFsLFW8Dy5wmiuxuzS5RkLWvqDnegLP/PaKsFfQmH4KRQtKskVP bfkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8McJnBYdzN6YGKR1d27uc2yGRo3bKsEZQGKGVyc9SSM=; b=h1NqkPhNSPNuYR8IFvVl7mEwG5fdkvL2p7zqeykwpjJy3NcR7Ixlpt9U9t1k8JYO7E 9bsbtb8FkDxfdkyEgPtrlYYx89eBNPkyHxK/LrILhEz8tAdmXFtRqGJOBvmBxKtBtpZL TgUQZrvl9YW/FEZ7OkMTs1cfrkNu+bI9ISS4vPRIXcZVR5J7b5sR0QQ0Bg/A4IBYO2SD KCOPqDNJt+RYltrLRbvtm26S30vSXQcBCgTGHunr/tHJpwHVv7zn8TjYl61Rm0HlKCR8 IkaSeMytazxLPy95O1pTvmfOBE/+r9nBVknH80mcTqENs0QUjl/qZMncneXCHtvvvy7r XEaA== X-Gm-Message-State: ALoCoQlHx6evO7cdYWZK2V8vbHwQizmbfa2K0qs4Ll+sIGe/PkRTiCufnwhuieVVXZdxTxGDNWDn MIME-Version: 1.0 X-Received: by 10.202.102.88 with SMTP id a85mr4878610oic.90.1446207298466; Fri, 30 Oct 2015 05:14:58 -0700 (PDT) Received: by 10.76.131.166 with HTTP; Fri, 30 Oct 2015 05:14:58 -0700 (PDT) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC22BC6494@SHSMSX101.ccr.corp.intel.com> References: <1445402801-27806-1-git-send-email-jijiang.liu@intel.com> <1445402801-27806-6-git-send-email-jijiang.liu@intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC22BC6494@SHSMSX101.ccr.corp.intel.com> Date: Fri, 30 Oct 2015 13:14:58 +0100 Message-ID: From: David Marchand To: "Liu, Jijiang" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 5/8] driver/virtio:enqueue vhost TX offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 12:14:59 -0000 On Fri, Oct 30, 2015 at 12:45 PM, Liu, Jijiang wrote: > > If the driver correctly reports negotiated offload capabilities (see my > previous comment on patch 3), there is no need for the test on > VIRTIO_NET_F_CSUM, because application is not supposed to ask for offloads > on driver that do not support them. > > > > > > > If the driver correctly reports negotiated offload capabilities, then > application in guest will set the ol_flags in mbuf based on these offload > capabilities. > > If the VIRTIO_NET_F_CSUM is not enabled, and there is no need to call > virtqueue_enqueue_offload() to check ol_flags in mbuf to see if the TX > checksum and TSO is set ,and it will not effect on the performance of > disabling TX checksum path as much as possible. > > So I think there is need for the check. > You are supposed to only handle mbuf with offloads if VIRTIO_NET_F_CSUM was enabled in the first place through the capabilities. So looking at ol_flags means that you implicitely check for VIRTIO_NET_F_CSUM. This is just an optimisation, so do as you like. Anyway, I just want to confirm, is this patchset for 2.2 ? -- David Marchand