netdev - RE: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE traffic in 82599

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:	Thu, 3 Sep 2009 22:07:51 -0700
From:	"Zou, Yi" <yi.zou@...el.com>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	David Miller <davem@...emloft.net>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: RE: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE
 traffic in 82599

>On Thu, 3 Sep 2009, David Miller wrote:
>
>> From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>> Date: Thu, 03 Sep 2009 17:56:10 -0700
>>
>> > From: Yi Zou <yi.zou@...el.com>
>> >
>> > This adds a simple selection of a FCoE tx queue based on the current cpu
>id to
>> > distribute transmission of FCoE traffic evenly among multiple FCoE
>transmit
>> > queues.
>> >
>> > Signed-off-by: Yi Zou <yi.zou@...el.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>>
>> Applied.
>>
>> Does it matter that arbitrary programs or other stacks could transmit
>> ETH_P_FCOE traffic as well?  Would that interfere with how this offload
>> hardware works now that you're directing all ETH_P_FCOE traffic to
>> FCOE rings?
>
>If another stack uses the FCoE Ethertype, the filtering we use in the
>qdisc layer to filter FCoE frames would assume they belong in the FCoE
>flow ID in the driver.  As long as the other stacks send standard FCoE
>frames, there won't be a problem.  If a stack uses the Ethertype but
>doesn't follow the standard FCoE frame format, then I'd say that stack was
>in need of being fixed.
>
>The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.
>
>Cheers,
>-PJ
Yes, any stack that wants to take advantage of 82599's FCoE offload
capability has to fake its traffic as FCoE frames.

Thanks,
yi

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