netdev - Re: [PATCH] bnx2x: tx-switching module parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 17 Apr 2012 13:22:09 +0300
From:	"Eilon Greenstein" <eilong@...adcom.com>
To:	"John Fastabend" <john.r.fastabend@...el.com>
cc:	davem@...emloft.net, "Stephen Hemminger" <shemminger@...tta.com>,
	"Ariel Elior" <ariele@...adcom.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] bnx2x: tx-switching module parameter

On Sun, 2012-04-15 at 22:11 -0700, John Fastabend wrote:
> On 2/16/2012 11:57 AM, Eilon Greenstein wrote:
> >>>> "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.
> 
> [...]
> 
> >>> But netdev is a great place to ask - are there other vendors out there
> >>> that requires this control over internal switching? If so, we can define
> >>> a new ethtool command. The alternative of using the ethtool private
> >>> flags seems just as inconvenient from administrators point of view and
> >>> also seem less appropriate since this configuration is more likely to be
> >>> the same for all PFs on the same machine.
> >>>
> 
> [...]
> 
> > OK, thanks John. Dave - please do not apply this patch. We need to look
> > at the alternatives suggested by John.
> > 
> > Thanks,
> > Eilon
> > 
> 
> Eilon, any progress with this? We need this to support VEPA modes in
> macvlan running over SR-IOV devices or other embedded switches. The
> problem being if the stacked device expects the packet to be sent
> to the reflexive relay on the switch in the SR-IOV case the embedded
> switch may not actually do this.

John, honestly, this is not at the top of the priority list for us right
now. If you would like to proceed, please do so - we will have to adopt
to what you suggest when we get back to this issue.

Thanks,
Eilon



--
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