public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Michael-Luke Jones <mlj28@cam.ac.uk>
Cc: Jeff Garzik <jeff@garzik.org>,
	netdev@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	Russell King <rmk@arm.linux.org.uk>,
	ARM Linux Mailing List <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 3/3] Intel IXP4xx network drivers
Date: Mon, 07 May 2007 21:57:21 +0200	[thread overview]
Message-ID: <m33b289zku.fsf@maximus.localdomain> (raw)
In-Reply-To: <86D26EBE-5899-468F-9C79-23E83E0DE04B@cam.ac.uk> (Michael-Luke Jones's message of "Mon, 7 May 2007 19:14:53 +0100")

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:

> Despite their name, Network Processing Engines are independent
> coprocessors which are only coincidentally attached to MACs for
> ethernet / WAN purposes. If Intel would allow us to compile code for
> these coprocessors, we could get them to do lots of things other than
> networking.

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.

> Crypto is not networking, and if the
> kernel gains ixp4xx crypto support, that should be possible to enable
> independently of networking.

Yep. Unfortunately I don't know in-kernel crypto code.

> They can also function as DMA engines,
> which should also be independent of networking functionality.

That's what the docs say. Not sure about real-life purpose of
such DMA engine, though.

> So, the NPE driver (which is basically ixp4xx specific) should be,
> for practical purposes, networking-code agnostic. As it is a lump of
> code talking to an architecture specific piece of hardware, it should
> live in arch/arm/ rather than arch-independent drivers/

Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
Not sure about details.

> As I understand it, functions to talk to the NPE should appear in the
> NPE driver. The NPE driver should then be called by ethernet/wan/
> crypto/dma(?) drivers to carry out the specific firmware-dependent
> tasks.

Actually, the NPE code does two things:
a) initialized NPEs and downloades the firmware
b) exchanges control messages with NPEs.
-- 
Krzysztof Halasa

  reply	other threads:[~2007-05-07 19:57 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 23:46 [PATCH 0/3] Intel IXP4xx network drivers Krzysztof Halasa
2007-05-07  0:06 ` [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select" Krzysztof Halasa
2007-05-07  1:44   ` Roman Zippel
2007-05-07  9:35     ` Krzysztof Halasa
2007-05-07 11:22       ` Roman Zippel
2007-05-07 11:56         ` Krzysztof Halasa
2007-05-07 13:17           ` Roman Zippel
2007-05-07 13:21             ` Jeff Garzik
2007-05-07 13:46               ` Roman Zippel
2007-05-07 16:50                 ` Krzysztof Halasa
2007-05-07 17:07                   ` Roman Zippel
2007-05-07 18:15                     ` Satyam Sharma
2007-05-07 20:31                       ` Jeff Garzik
2007-05-07 20:49                         ` Satyam Sharma
2007-05-07 20:50                         ` Randy Dunlap
2007-05-07 22:39                           ` Satyam Sharma
2007-05-07 22:52                             ` Randy Dunlap
2007-05-07 20:57                         ` Roman Zippel
2007-05-07 20:54                     ` Krzysztof Halasa
2007-05-07 21:02                     ` [PATCH] Use menuconfig objects II - netdev/wan Krzysztof Halasa
2007-05-07 21:08                     ` [PATCH 1a/3] WAN Kconfig: change "depends on HDLC" to "select" Krzysztof Halasa
2007-05-07  0:07 ` [PATCH 2/3] ARM: include IXP4xx "fuses" support Krzysztof Halasa
2007-05-07  5:24   ` Alexey Zaytsev
2007-05-07 10:24     ` Krzysztof Halasa
2007-05-07  0:07 ` [PATCH 3/3] Intel IXP4xx network drivers Krzysztof Halasa
2007-05-07 12:59   ` Michael-Luke Jones
2007-05-07 17:12     ` Krzysztof Halasa
2007-05-07 17:52       ` Christian Hohnstaedt
2007-05-07 20:00         ` Krzysztof Halasa
2007-05-08 11:48           ` Lennert Buytenhek
2007-05-08 13:47             ` Krzysztof Halasa
2007-05-07 18:14       ` Michael-Luke Jones
2007-05-07 19:57         ` Krzysztof Halasa [this message]
2007-05-07 20:18           ` Michael-Luke Jones
2007-05-08 11:46             ` Lennert Buytenhek
2007-05-08  0:11           ` [PATCH] Intel IXP4xx network drivers v.2 Krzysztof Halasa
2007-05-08  0:36           ` [PATCH] Intel IXP4xx network drivers v.2 - NPE Krzysztof Halasa
2007-05-08  7:02             ` Michael-Luke Jones
2007-05-08 13:56               ` Krzysztof Halasa
2007-05-08  0:46           ` [PATCH] Intel IXP4xx network drivers v.3 - QMGR Krzysztof Halasa
2007-05-08  7:05             ` Michael-Luke Jones
2007-05-08 13:57               ` Krzysztof Halasa
2007-05-08 11:32             ` Lennert Buytenhek
2007-05-08 12:47               ` Alexey Zaytsev
2007-05-08 12:59                 ` Lennert Buytenhek
2007-05-08 14:12               ` Krzysztof Halasa
2007-05-08 14:40                 ` Lennert Buytenhek
2007-05-08 16:59                   ` Krzysztof Halasa
2007-05-09 10:21                     ` Lennert Buytenhek
2007-05-10 14:08                       ` Krzysztof Halasa
2007-05-08  1:19           ` [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS Krzysztof Halasa
2007-05-08  5:28             ` Jeff Garzik
2007-05-08  7:22             ` Michael-Luke Jones
2007-05-08 11:37             ` Lennert Buytenhek
2007-05-08 14:31               ` Krzysztof Halasa
2007-05-08 14:53                 ` Lennert Buytenhek
2007-05-08 17:17                   ` Krzysztof Halasa
2007-05-08 11:40   ` [PATCH 3/3] Intel IXP4xx network drivers Lennert Buytenhek
2007-05-07 10:27 ` [PATCH 2a/3] " Krzysztof Halasa
2007-05-08  1:40 ` [PATCH 0/3] " Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m33b289zku.fsf@maximus.localdomain \
    --to=khc@pm.waw.pl \
    --cc=jeff@garzik.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlj28@cam.ac.uk \
    --cc=netdev@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox