Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Intel\s+and\s+TOE\s+in\s+the\s+news\s*$/: 112 ]

Total 112 documents matching your query.

1. Re: Intel and TOE in the news (score: 1)
Author: nybbz@xxxxxxxx>
Date: Wed, 2 Mar 2005 14:48:24 +0100
It indeed appears to be something like the IXP2000. http://www.intel.com/technology/ioacceleration/index.htm Quote from ServerNetworkIOAccel.pdf (which is otherwise content-free): Lightweight Threadi
/archives/netdev/2005-03/msg00065.html (9,090 bytes)

2. RE: Intel and TOE in the news (score: 1)
Author: <yoshfuji@xxxxxxxxxx>
Date: Wed, 2 Mar 2005 09:34:58 -0800
It was a good presentation, I suspect some/most of you guys may be able to get it through your company attendees. At any rate, don't worry - details will probably come out soon enough since kernel s
/archives/netdev/2005-03/msg00076.html (10,892 bytes)

3. Re: Intel and TOE in the news (score: 1)
Author: elte <laforge@xxxxxxxxxxxx>
Date: Sun, 6 Mar 2005 12:21:04 +0100
Sorry for my late catch-up, didn't have time to read all mailinglists for some time. It's actually becoming more and more common. But there are only MCH's with a single CSA port, so you will never be
/archives/netdev/2005-03/msg00341.html (9,706 bytes)

4. Intel and TOE in the news (score: 1)
Author: xx>
Date: Fri, 18 Feb 2005 22:44:45 -0500
http://www.theregister.co.uk/2005/02/18/intel_tcpip_attack/ Intel to attack greedy TCP/IP stack Intel next year will plant itself square in the middle of the budding market for systems that speed net
/archives/netdev/2005-02/msg00657.html (8,652 bytes)

5. Re: Intel and TOE in the news (score: 1)
Author: xxxxx>
Date: Sat, 19 Feb 2005 05:10:07 +0100
I wonder if they could just take the network processing circuitry from the IXP2800 (an extra 16-core (!) RISCy processor on-die, dedicated to doing just network stuff, and a 10gbps pipe going straigh
/archives/netdev/2005-02/msg00658.html (8,932 bytes)

6. Re: Intel and TOE in the news (score: 1)
Author: xxxxxxxx>
Date: Sat, 19 Feb 2005 11:46:24 -0800
No, that would be garbage. Read what they are doing. The idea is not to have all of this network protocol logic off-cpu, the idea is to "reduce some of the time a processor typically spends waiting f
/archives/netdev/2005-02/msg00675.html (9,705 bytes)

7. Re: Intel and TOE in the news (score: 1)
Author: xxxxxxxxx>
Date: Sat, 19 Feb 2005 21:27:31 +0100
<speculating freely> It would be nice if the NIC could asynchronously trigger prefetches in the CPU. Currently a lot of the packet processing cost goes to waiting for read cache misses. E.g. - NIC re
/archives/netdev/2005-02/msg00678.html (9,728 bytes)

8. Re: Intel and TOE in the news (score: 1)
Author: herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 19 Feb 2005 21:29:32 +0100
I agree that offloading just for the sake of offloading is silly. The reason a 1.4GHz IXP2800 processes 15Mpps while a high-end PC hardly does 1Mpps is exactly because the PC spends all of its cycles
/archives/netdev/2005-02/msg00679.html (11,530 bytes)

9. Re: Intel and TOE in the news (score: 1)
Author: er" <davem@xxxxxxxxxxxxx>
Date: Sat, 19 Feb 2005 21:32:04 +0100
I've been told that this is something that the BCM-1250 can do. The MACs are in the CPU, and they can (reportedly) DMA the packet headers straight into L2. --L
/archives/netdev/2005-02/msg00680.html (9,445 bytes)

10. Re: Intel and TOE in the news (score: 1)
Author: xxxxxx>
Date: Sun, 20 Feb 2005 08:46:07 -0800
Just FYI :), Freescale 85xx TSECs can prefetch buffers into L2 cache. IIRC they call it buffer "stashing" and gianfar driver has a config option to enable such behavior. But in embedded world you usu
/archives/netdev/2005-02/msg00693.html (10,092 bytes)

11. Re: Intel and TOE in the news (score: 1)
Author: xx>
Date: Sun, 20 Feb 2005 11:45:02 -0800
<speculating freely> It would be nice if the NIC could asynchronously trigger prefetches in the CPU. Currently a lot of the packet processing cost goes to waiting for read cache misses. E.g. - NIC re
/archives/netdev/2005-02/msg00697.html (10,069 bytes)

12. Re: Intel and TOE in the news (score: 1)
Author: hard Dawe <rich@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 16:20:15 -0500
rick> With all the interrupt avoidance that is going-on these days, rick> would prefetching in the driver be sufficient? Presumably the rick> driver is going to be processing multiple packets at a ti
/archives/netdev/2005-02/msg00699.html (11,896 bytes)

13. Re: Intel and TOE in the news (score: 1)
Author: <jdmason@xxxxxxxxxx>
Date: Sun, 20 Feb 2005 22:29:45 +0100
Yes, we came up with this idea some years ago too ;-). It was even tried in some simple variants, but didn't work very well: - The time between finding out you have a packet and it being processed is
/archives/netdev/2005-02/msg00700.html (12,636 bytes)

14. RE: Intel and TOE in the news (score: 1)
Author: n Mason <jdmason@xxxxxxxxxx>
Date: Sun, 20 Feb 2005 14:43:59 -0800
This is an interesting idea, we'll play around... BTW - does anybody know if it's possible to indicate multiple receive packets? In other OS drivers we have an option to indicate a "packet train" th
/archives/netdev/2005-02/msg00701.html (14,175 bytes)

15. Re: Intel and TOE in the news (score: 1)
Author: es2@xxxxxx>
Date: Mon, 21 Feb 2005 00:07:13 +0100
What exactly? The software only shadow table? You can always call netif_rx() multiple times from the interrupt. The function doesn't do the full packet processing, but just stuffs the packet into a C
/archives/netdev/2005-02/msg00702.html (11,823 bytes)

16. RE: Intel and TOE in the news (score: 1)
Author: xxxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 17:57:56 -0800
That's what we do, simply because interrupts are coalesced. There's the netif_rx's own per-packet overhead (including the call itself) that arguably could be optimized.. Our experimental Linux drive
/archives/netdev/2005-02/msg00709.html (13,651 bytes)

17. Re: Intel and TOE in the news (score: 1)
Author: >
Date: Sun, 20 Feb 2005 21:37:38 -0500
Alex Aizman wrote: Our experimental Linux driver already supports MSI and MSI-X (the latter not tested). Once/if multi-MSI support in Linux becomes available it'd be practically possible to scale TCP
/archives/netdev/2005-02/msg00713.html (10,145 bytes)

18. RE: Intel and TOE in the news (score: 1)
Author: xxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 19:31:55 -0800
Yes, this is what we currently do; I was rather thinking about the option to indicate multiple packets in a single call (say as a linked list). Alternative (rather, complimentary) approach is to col
/archives/netdev/2005-02/msg00714.html (13,611 bytes)

19. Re: Intel and TOE in the news (score: 1)
Author: oshfuji@xxxxxxxxxxxxxx>
Date: Mon, 21 Feb 2005 12:37:56 +0100
netif_rx should be pretty cheap. It could be probably optimized more (e.g. no local_irq_save if you know you're comming from a interrupt or somehow avoiding the atomic reference count increase on the
/archives/netdev/2005-02/msg00723.html (10,989 bytes)

20. Re: Intel and TOE in the news (score: 1)
Author:
Date: Mon, 21 Feb 2005 12:50:06 +0100
For the non NAPI case the packet is just put into a queue anyways. If you want to process packets as lists then just the consumer of the queue would need to be changed. I agree that it would be a goo
/archives/netdev/2005-02/msg00724.html (11,543 bytes)


This search system is powered by Namazu