From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by dpdk.org (Postfix) with ESMTP id E1B0768FD for ; Fri, 4 Oct 2013 20:22:22 +0200 (CEST) Received: by mail-pb0-f48.google.com with SMTP id ma3so4272695pbc.7 for ; Fri, 04 Oct 2013 11:23:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=tf8z0cn2vOJHXjjz832Ikuj3HukGda1hzDi0hwg4Do8=; b=lFW4KZZyzZZ8KH24PjpQih6YFnhSjrWVb8uwbxnCsOaI1hH8J+SnfPJyOmjSOrDOl/ 8lnRyUGG/aNYDuVk99z5AK71sVgt6Xf0AyxEumsvuFM0w1j5U+BwU+e6Hhf6LQisyKOs ylvjIeqwFQYjJmO9iapZfYs8gMsll/o6lyuAdBKL4tZM+tTZ5pPwsxfQRqj9J3jBsNyt kSsxeuU3mxoVMXb+OOe0JqCW97zd+5YjCvR2F3IwAsDCAKJxI9lapuykK0seKzXzrh7G 8tp4OJtJxfWlZ7KofXpFuffqovZMZelogbZt879qoG5tM5eFpxu4TfHrZ3e9r9vZqFYM Cl9A== X-Gm-Message-State: ALoCoQlf1kYqo/1WYtKmvKgRyLWeW/WyYtXsc5IvQNuhrwgUQ4BY3PfcJVmNSfXTH3JgDi7s2Xh2 X-Received: by 10.68.29.36 with SMTP id g4mr7951497pbh.145.1380910985846; Fri, 04 Oct 2013 11:23:05 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51]) by mx.google.com with ESMTPSA id lm2sm19785926pab.2.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 04 Oct 2013 11:23:05 -0700 (PDT) Date: Fri, 4 Oct 2013 11:23:02 -0700 From: Stephen Hemminger To: jigsaw Message-ID: <20131004112302.50693f04@nehalam.linuxnetplumber.net> In-Reply-To: References: <1380906413-3406-1-git-send-email-jigsaw@gmail.com> <20131004104030.206356dd@nehalam.linuxnetplumber.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support 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, 04 Oct 2013 18:22:23 -0000 On Fri, 4 Oct 2013 20:54:31 +0300 jigsaw wrote: > Hi Stephen, > > > >>This will work for local generated packets but overlapping existing field won't work well for forwarding. > So adding a new mss field in mbuf could be the way out? or I > misunderstand something. > > >> What we want to be able to do is to take offload (jumbo) packets in with from virtio > Sorry I don't understand why TSO is connected to virtio. Could you > give more details here? > Are you suggesting this TSO patch overlaps your work, or it should be > based on your work? I am working on a better virtio driver. Already have lots more features working, and doing better offload support is planned. TSO is a subset of the more generic segment offload (GSO) on Linux. With virtio is possible to receive GSO packets as well as send them. This feature is negotiated between guest and host. The idea is that between guests they can exchange jumbo (64K) packets even with a smaller MTU. This helps in many ways. One example is only a single route lookup is needed. Another issue is that the current DPDK model of offload flags for checksum is problematic. It matches what is available in Intel hardware and is not easily generalizable to other devices. Current DPDK flag is checksum bad. I would like to change it to checksum known good. Then drivers which dont' do checksum would leave it 0, but if receive checksum is known good set it to 1. Basically 1 means known good, and 0 means unknown (or bad). Higher level software can then do sw checksum if necessary.