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]
Message-ID: <7C88852EF6F99F4EB538472FCFEBE22240F1180C@orsmsx509.amr.corp.intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ