Having thought about it a bit more, a layout similar to the one proposed by you may make sense. Michael-Luke Jones <mlj28@cam.ac.uk> writes:Not sure about that. Intel doesn't say much about it, but I think one can safely assume that while NPEs can probably be programmed to do other things, their performance comes not from NPE firmware but from specialized network coprocessors (not NPEs) which can only do (in hardware) things like Ethernet, HDLC, bit sync, CRC16/32, and MD5/SHA-1/DES/AES. I think you can even use MD5 and SHA-1 without any firmware (but would have to check this info). Note that while certain CPUs have the same set of NPEs, they are missing some network coprocessors and can't do, for example, crypto. OTOH, yes, they are not, strictly speaking, only network processors. Yep. Unfortunately I don't know in-kernel crypto code. That's what the docs say. Not sure about real-life purpose of such DMA engine, though. Well, I'm told that (compatible) NPEs are present on other IXP CPUs. Not sure about details. Actually, the NPE code does two things: a) initialized NPEs and downloades the firmware b) exchanges control messages with NPEs. -- Krzysztof Halasa -
| Paul Jackson | Re: cpuset-remove-sched-domain-hooks-from-cpusets |
| James Bottomley | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| David Miller | Slow DOWN, please!!! |
| Masami Hiramatsu | Re: [RFC PATCH v4] Unified trace buffer |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Parag Warudkar | Re: 2.6.29-rc3: tg3 dead after resume |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
