Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933570AbZKXQ4S (ORCPT ); Tue, 24 Nov 2009 11:56:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933559AbZKXQ4R (ORCPT ); Tue, 24 Nov 2009 11:56:17 -0500 Received: from stinky.trash.net ([213.144.137.162]:40158 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933471AbZKXQ4O (ORCPT ); Tue, 24 Nov 2009 11:56:14 -0500 Message-ID: <4B0C1031.4050803@trash.net> Date: Tue, 24 Nov 2009 17:56:17 +0100 From: Patrick McHardy User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Arnd Bergmann , virtualization@lists.linux-foundation.org, Herbert Xu , Eric Dumazet , Anna Fischer , netdev@vger.kernel.org, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Mark Smith , Gerhard Stenzel , Jens Osterkamp , Patrick Mullaney , Stephen Hemminger , Edge Virtual Bridging , David Miller Subject: Re: [PATCH 1/4] veth: move loopback logic to common location References: <1259024166-28158-1-git-send-email-arnd@arndb.de> <200911241002.20904.arnd@arndb.de> <4B0BB2A7.5040707@trash.net> <200911241034.43961.arnd@arndb.de> <4B0BB818.6090509@trash.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2415 Lines: 46 Eric W. Biederman wrote: > Patrick McHardy writes: > >>>>> I did all my testing with macvlan interfaces in separate namespaces >>>>> communicating with each other, so I'd assume that we should always >>>>> clear skb->mark and skb->dst in this function. >>>> Good point, in that case we probably should clear it as well. But >>>> in the non-namespace case the TC classification currently works and >>>> this is consistent with any other virtual device driver, so it >>>> should continue to work. >>> Do you think we should be able to use TC to direct traffic between >>> macvlans on the same underlying device in bridge mode? It does sound >>> useful, but I'm not sure how to implement that or if you'd expect >>> it to work with the current code. If we support that, it should probably >>> also work with namespaces, by consuming the mark in the macvlan >>> and veth drivers. >> I don't think its necessary, we bypass outgoing queuing anyways. >> But if you'd want to add it, just keeping the skb->mark clearing >> in veth should work from what I can tell. > > veth doesn't have an outgoing queue. The reason we clear skb->mark > in veth is because when reentering the networking stack the packet > needs to be reclassified. At the point of loopback we are talking > a packet that has at least logically gone out of the machine on a > wire and come back into the machine on another physical interface. > > So it seems to me we should have consistent handling for macvlans, > veth, for the cases where we are looping packets back around. In > practice I expect all of those cases are going to be cross namespace > as otherwise we would have intercepted the packet before going > out a physical interface. Agreed on the looping case, that's what we're doing now. In the layered case (macvlan -> eth0) its common behaviour to keep the mark however. But in case of different namespaces, I think macvlan should also clear the mark on the dev_queue_xmit() path since this is just a shortcut to looping the packets through veth. In fact probably both of them should also clear skb->priority so other namespaces don't accidentally misclassify packets. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/