From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by dpdk.org (Postfix) with ESMTP id 7A37868C8 for ; Fri, 4 Oct 2013 19:53:48 +0200 (CEST) Received: by mail-ie0-f173.google.com with SMTP id ar20so9758134iec.4 for ; Fri, 04 Oct 2013 10:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jrTgQT5qD9z2YuBdP7xrXS4sFB6VTZ4aYguuY7r+D6U=; b=Dwgjj7uYMNTX1dj2oZRpiU6znz7BJdYrQntl/+xe4Bv9OuHJNdwHr4sh/ZxNve8VNb TTtvW3xkdnzDfoIUkqHTsuYSj1lNutE3M7siULrHAZcsXDokEJw14ePzZyQuRyay4/Mh HKQJE1hKMpvefpEfIR55QPITSDJhTjF1/mZHv4908czFACKz2VU2Ko5ZPwQjLvYNkj8h +zI+UotJbDBiogEoLIy6EPesTqKDtd5gTNpec3Xo2mn7qdUfaTIytmXhCxDi/2Ej9yv+ owPSEz0qqmlL1EdMLaljpUik7vMR5LvKsw/RIXtRgbBKCZo7QK9AismCvEWCrWcnBz1X 9tJQ== MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr7535592igg.23.1380909271447; Fri, 04 Oct 2013 10:54:31 -0700 (PDT) Received: by 10.42.67.205 with HTTP; Fri, 4 Oct 2013 10:54:31 -0700 (PDT) In-Reply-To: <20131004104030.206356dd@nehalam.linuxnetplumber.net> References: <1380906413-3406-1-git-send-email-jigsaw@gmail.com> <20131004104030.206356dd@nehalam.linuxnetplumber.net> Date: Fri, 4 Oct 2013 20:54:31 +0300 Message-ID: From: jigsaw To: Stephen Hemminger Content-Type: text/plain; charset=ISO-8859-1 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 17:53:48 -0000 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? thx & rgds, -Qinglai On Fri, Oct 4, 2013 at 8:40 PM, Stephen Hemminger wrote: > On Fri, 4 Oct 2013 20:06:52 +0300 > Qinglai Xiao wrote: > >> This patch is a draft of TSO on 82599. That is, it is not expected to be >> accepted as is. >> The problem is where to put the mss field. In this patch, the mss is put in >> the union of hash in rte_pktmbuf. It is not the best place, but it is quite >> convenient, since hash is not used in TX procedure. >> The idea is to avoid increasing sizeof(struct rte_pktmbuf), while keeping mss >> easy to access. >> >> However, the hash is also misleading, coz mss has nothing to do with Rx hash. >> A more formal way could be rename hash as below: >> >> union { >> uint32_t data; >> struct rx_hash hash; >> uint32_t tx_mss; >> } misc; >> >> It is gonna be a major change coz it affects the core data structure. >> >> Any comments will be appreciated. >> >> Qinglai Xiao (1): >> ixgbe: TCP/UDP segment offload support on 82599. >> >> lib/librte_mbuf/rte_mbuf.h | 6 +++++- >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 32 +++++++++++++++++++++++++++++--- >> 2 files changed, 34 insertions(+), 4 deletions(-) >> > > This will work for local generated packets but overlapping existing > field won't work well for forwarding. > > What we want to be able to do is to take offload (jumbo) packets in > with from virtio (need better driver support which I am doing), and then > send them through to network devices. >