[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120216094936.3449e6ef@nehalam.linuxnetplumber.net>
Date: Thu, 16 Feb 2012 09:49:36 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: "Ariel Elior" <ariele@...adcom.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
"Eilon Greenstein" <eilong@...adcom.com>
Subject: Re: [PATCH] bnx2x: tx-switching module parameter
On Thu, 16 Feb 2012 16:05:12 +0200
"Ariel Elior" <ariele@...adcom.com> wrote:
> In 57712 and 578xx the tx-switching module parameter allows the user to control
> whether outgoing traffic can be loopbacked into the device in case there is a
> relevant client for the data using the same device for rx.
> A classic example where this is necessary is for virtualization purposes, where
> one vm is transmitting data to another, while both use different pci functions of
> the same port of the same nic.
>
> In case there is a promiscuous client in the rx (which wants to receive all
> data) or if the traffic is broadcast, traffic may be sent on both the loopback
> channel and the physical wire.
>
> The reason tx-switching is controlled by a module parameter is twofold:
> 1. There is a certain performance penalty for tx-switching because:
> a. every packet must be compared against the receiver clients.
> b. duplicated traffic being loopbacked can consume a significant portion of
> the overall bandwidth, depending on the scenario.
> 2. Tx-switching doesn't make much sense as a per function parameter, but should
> rather be controlled uniformly for the entire device. The reason is that if one
> interface wants to be able to send data on the loopback it is not enough to
> enable tx-switching for that interface, as the target interface must also
> register its rx classification information where the transmitting interface can
> find it. One would still have to use the module parameter in each VM, though.
>
> Signed-off-by: Ariel Elior <ariele@...adcom.com>
> Signed-off-by: Eilon Greenstein <eilong@...adcom.com>
Module parameters are the hardware vendors friend, but the system
integrators nightmare. Although you think your hardware is special
but it isn't some other vendor will have same idea, how is user and
distribution supposed to control it?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists