Doug, On Sep 23, 2014, at 9:49 PM, Doug Anderson <dfaussie...@gmail.com> wrote:
> How does one use the IDX field in an advanced transmit data descriptor? > > I'm trying to understand this statement from > http://www.intel.com/content/www/us/en/ethernet-controllers/82599-10-gbe-controller-datasheet.html > : > >> From page 344 regarding transmit contexts: > > "The 82599 supports two contexts for each of its 128 transmit queues. The > IDX > bit contains an index to one of these two contexts. Each advanced data > descriptor that uses > any of the advanced offloading features must refer to a context by > the IDX field." > > Where are these two contexts? How do I access them? It seems, in the > ixgbe driver for linux, that the idx field in the advanced transmit data > descriptor is never set ( is left at zero ) but rather an advanced transmit > context descriptor is put in the tx ring buffer before an advanced transmit > data descriptor. For example, if you want to do offloading, you: > > 1. fill in an advanced transmit context descriptor and put it on the > tx_ring ( ixgbe_tx_ctxtdesc > <http://lxr.free-electrons.com/ident?i=ixgbe_tx_ctxtdesc> ) > 2. fill in a transmit data descriptor and put it on the tx_ring > > Why doesn't it: > > 1. fill in one of these two contexts that are available on each 128 > transmit queues and set it up for offloading. > 2. fill in the idx field of the advanced transmit data so that idx selects > the context that was filled out in step (1). > > Which is what the documentation seems to imply. Does the documentation > even say that an advanced transmit context descriptor applies to the next > packet sent if idx is left at zero? There are two contexts per transmit queue. They are set by context descriptors sent to the corresponding queue. The current Linux driver only ever uses context 0 in each queue. The documentation does not say that an advanced transmit descriptor applies to the next packet, it just happens that the current Linux driver always emits its context 0 descriptor right before it emits the data descriptor that will use it. It is pretty simple. I'm sure there are a variety of ways to take advantage of a second context, especially for some dedicated applications. It just happens right now that the normal Linux driver doesn't have a use case for a second context descriptor. If we tried to remember and possibly reuse what was in the two contexts, the overhead of those checks would be right in the hot path of the driver and in many cases performance would suffer from the added checks. The purpose of the Linux driver is not use fully use every feature that the hardware provides, but to deliver the best performance possible for the widest array of use-cases. A driver tuned to a particular environment may be able to get a benefit from using additional features, but often that would be at the expense of the driver's behavior in other environments. -- Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
