From owner-freebsd-net@FreeBSD.ORG Fri Aug 23 07:42:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8C3AD80 for ; Fri, 23 Aug 2013 07:42:30 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33012234D for ; Fri, 23 Aug 2013 07:42:29 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ep20so219489lab.15 for ; Fri, 23 Aug 2013 00:42:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=0CGrGXuyUFc305JWFuPO8S9ivuwClrAseRifURYETDQ=; b=kCd+oJvxZNmO0I90odtndOsJD6pbhDVCPA22omFRZda3I+0hhu31C1GnhdwpTULCSs 6BZussSke6qCnMIjCxCPgrPThi00vC5iMiIxeNvFe74JXZ5icrL5h9eW4/GA3Br6T2Kf 2isLipnXCG2i6yrN/s1l/OXtYguFwLXiyQ0Ph3lzy4EVjBYYR7qUBkLu4OJ+0d6KXFCF +6sLZLGMuz3wo7GOfpLA9WTpDvP/I2kKKURiZGPnZT/k5tcC97QToJXfgNcEni8loK43 82ja8Fj+jKRU9Q9Wiy0mCKAaGIkPPB3TSMWialcKRWHFzJ+Gxi7D4yL/tauda+ay9sYq JMwg== X-Gm-Message-State: ALoCoQnXE3H0YqVjTqDodQumzX8RL7iy2m1G2T90GMU8Ayc+kTxBS6qMCLtC8znosJ+WPCa7Z1Pe X-Received: by 10.112.14.102 with SMTP id o6mr14732119lbc.28.1377242021705; Fri, 23 Aug 2013 00:13:41 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.23.101 with HTTP; Fri, 23 Aug 2013 00:13:21 -0700 (PDT) In-Reply-To: <521708E8.4000105@freebsd.org> References: <521708E8.4000105@freebsd.org> From: Juli Mallett Date: Fri, 23 Aug 2013 00:13:21 -0700 X-Google-Sender-Auth: NocASFNudMTiQxKQI3gpDbyRrCs Message-ID: Subject: Re: Netmap ixgbe stripping Vlan tags To: Andre Oppermann Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Harika Tandra X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 07:42:30 -0000 On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann wrote: > On 23.08.2013 00:36, Harika Tandra wrote: > >> Hi all, >> >> I am running Netmap with "intel 10G 82598EB" card in promiscuous mode. >> While capturing packets via Netmap the driver is stripping off Vlan tags. >> I tested my setup, I am able to see Vlan tags when the same card is in >> promiscuous >> mode without Netmap. >> >> This maybe due to the netmap related changes to the device driver code. >> But I don't know much about drivers. I would appreciate any help or >> pointer >> regarding this. >> > > This is standard behavior in FreeBSD drivers where the vlan header is > removed > and the vlan tag is placed in an mbuf field. Together with netmap it > doesn't > make sense of course and the driver should disable it when switching to > netmap > mode. > I think this runs counter to the netmap ethos some (as I understand it.) In the same way that netmap doesn't enable promiscuous mode since you may be doing non-promiscuous processing with netmap, it also should leave whether VLAN_HWFILTER (or whatever) is enabled up to the program or the user in question. It would be nice if it could do the state management for these things (to ensure the interface goes back to its original state if the program crashes), but as yet it can't. There are lots of passive capture applications where you might not care about having the VLAN tags intact and so would prefer to have them stripped. If there's a bug here, it's that packet metadata is lost going into netmap entirely, not that the VLAN tags aren't in the frame. > The general usefulness of hardware vlan tag stripping/insertion is > debatable as > it doesn't gain much, if anything, and was intended for an entirely > different > purpose, namely to help the windows kernel over its total lack of vlan > awareness. > It also helps (slightly) reduce overhead in packet processing where you just want to move data from card to host as fast as possible. > It can be argued that in FreeBSD hardware vlan tag insert/removal is an > unnecessary > misfeature and only complicates things. Especially in the context of > multi-vlan > stacking. Doing it in software would be in fact just as fast remove a bit > of code > from the drivers. Are you sure? While that may hold up for ixgbe (though I'd say it doesn't, at least without packets going straight into cache so there's no penalty for accessing parts of the packet you don't care about, again looking at the netmap case really) it doesn't hold up for low-powered network processors with very fast offload engines. (NB: I'd rather see it gone; I think it's an annoying complication when writing network drivers [which have way too many fiddly bits; I was bound to dislike some aspect of 'tools not policy' eventually, I guess], or if it stays I'd rather see it be a mandatory option on hardware where there's no penalty for using it. Some hardware's performance falls off spectacularly with this kind of offloading enabled, losing whatever gains stripping unnecessary data provided.) Thanks, Juli.