Lennert Buytenhek  writes:
> The board support code knows such things as that the "front ethernet

quoted text
> port" on the board is connected to the CPU's MII port number #2, but

> the board support code does _not_ know that MII port number #2

> corresponds to "ixp4xx hardware queue #5."

Sure. And I don't want it to know.
It has to pick up any available queue for RX, that is. If the

board code knows it uses ETH connected to NPE-B and NPE-C, and

HSS-0 connected (obviously) to NPE-A, and it wants some crypto

functions etc., it can pick a queue which normally belongs to

HSS-1. If the code knows the board has both HSS and only NPE-B

Ethernet, it can use one of NPE-C Ethernet's queues. It's that

simple.
The Ethernet (and HSS etc.) driver knows it has to use queue 24 for

NPE-B Ethernet's TX and 27 for TX and so on, this is fixed in the

firmware so I don't let the board code mess with that. The

Ethernet RX queue is different, we can just make something up and

tell NPE about that.
That's BTW the same thing you would want to do with SRAM - except

that the SRAM allocator is technically possible, while making

queue assignments needs knowledge about the hardware.
> If Intel puts out a firmware update next month, and your ethernet

quoted text
> driver is modified to take advantage of the new features in that

> firmware and starts depending on the newer version of that firmware,

> we will have to modify every ixp4xx board support file in case the

> firmware update modifies the ixp4xx queue numbers in use.

Nope, we just modify Ethernet driver:

drivers/net/arm/ixp4xx_eth.c:

#define TX_QUEUE(plat)          (NPE_ID(port) + 23)

#define RXFREE_QUEUE(plat)      (NPE_ID(port) + 26)

#define TXDONE_QUEUE            31
> The

quoted text
> mapping from hardware ports (MII port #0, MII port #6, HSS port

> #42, whatever) to ixp4xx hardware queue numbers (0-63) should _not_

> be put in every single ixp4xx board support file.

I've never considered doing that :-)
drivers/net/wan/ixp4xx_hss.c:

/* Queue IDs */

#define HSS0_CHL_RXTRIG_QUEUE   12      /* orig size = 32 dwords */

#define HSS0_PKT_RX_QUEUE       13      /* orig size = 32 dwords */

#define HSS0_PKT_TX0_QUEUE      14      /* orig size = 16 dwords */

#define HSS0_PKT_TX1_QUEUE      15

#define HSS0_PKT_TX2_QUEUE      16

#define HSS0_PKT_TX3_QUEUE      17

#define HSS0_PKT_RXFREE0_QUEUE  18      /* orig size = 16 dwords */

#define HSS0_PKT_RXFREE1_QUEUE  19

#define HSS0_PKT_RXFREE2_QUEUE  20

#define HSS0_PKT_RXFREE3_QUEUE  21

#define HSS0_PKT_TXDONE_QUEUE   22      /* orig size = 64 dwords */
#define HSS1_CHL_RXTRIG_QUEUE   10

#define HSS1_PKT_RX_QUEUE       0

#define HSS1_PKT_TX0_QUEUE      5

#define HSS1_PKT_TX1_QUEUE      6

#define HSS1_PKT_TX2_QUEUE      7

#define HSS1_PKT_TX3_QUEUE      8

#define HSS1_PKT_RXFREE0_QUEUE  1

#define HSS1_PKT_RXFREE1_QUEUE  2

#define HSS1_PKT_RXFREE2_QUEUE  3

#define HSS1_PKT_RXFREE3_QUEUE  4

#define HSS1_PKT_TXDONE_QUEUE   9
>> Without them the code in question is hardly readable,

quoted text
>

> You can read Polish, how can you complain about code readability. :-))

Well, you may have the point, but I also care about others :-)

--

Krzysztof Halasa

-

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/