From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Date: Wed, 09 Jan 2013 11:51:03 -0800 Message-ID: <1357761063.27446.60.camel@edumazet-glaptop> References: <1357712850.27446.28.camel@edumazet-glaptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: tcpdump-workers@lists.tcpdump.org, Paul Pearce , netdev@vger.kernel.org, dborkman , edumazet , Jiri Pirko To: Ani Sinha Return-path: Received: from mail-da0-f48.google.com ([209.85.210.48]:48356 "EHLO mail-da0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932231Ab3AITvG (ORCPT ); Wed, 9 Jan 2013 14:51:06 -0500 Received: by mail-da0-f48.google.com with SMTP id k18so905308dae.21 for ; Wed, 09 Jan 2013 11:51:05 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote: > This is wrong. Accelerated or not, the kernel code was organized to > have the tags in the packet aux data. So I think this is how user land > should be coded as well. You have your opinion, thats good. My opinion as a kernel developer is that the network tap is here to have a copy of the exact frame given to the _device_. Because in the end, users will complain to netdev, giving us tcpdump traces. And if these traces have nothing to do with what is given to the device, they are almost useless. If you want other taps, and catch frames before/after various netfilter hooks, segmentations, vlan accel, tunnels, or before GRO layer, thats a totally different request. A packet can be modified by a lot of layers in the kernel. And yes, BPF filters can be incredibly complex, but it appears kernel is not a piece of cake.