[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.WNT.4.64.0909032107410.800@ppwaskie-MOBL2.amr.corp.intel.com>
Date: Thu, 3 Sep 2009 21:12:46 -0700 (Pacific Daylight Time)
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To: 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>, "Zou, Yi" <yi.zou@...el.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
--
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