gigabit switch that supports jumbo frames?

Marris wrote in part:

Yes, it is. But it is also an appreciable fraction (8%). This is at least 8% more CPU load, and might even by 8% less throughput if the etherchip cannot continue to receive while the interrupt is being serviced.

-- Robert

Reply to
Robert Redelmeier
Loading thread data ...

Which is why I was advocating NIC access to the virtual memory space; this allows data to flow from the wire to physical memory without CPU intervention, eliminating that portion of the overhead.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

There still needs to be some sort of notification to the application that there is data ready to see. Now, that may be far from a per-frame sort of thing I guess...

rick jones

Reply to
Rick Jones

Rich Seifert wrote in part:

Quite reasonably so. Better etherchips support PCI busmastering (a form of DMA) that permits the NIC to drop directly into physical RAM.

This is usually mapped into kernel memory so the kernel can process the packet and decide which process to send it to. Sometimes this can be done "zero copy".

The general problem with dropping packets directly to apps is security -- how do you know that everything coming down the wire can be seen by that app?

There is also the port-sharing problem: how do you keep multiple connections to the same port from getting confused? A webserver is a perfect example. MS-IIS and Apache take very different approaches: Apache uses OS TCP connection services and respawns. AFAIK, MS-IIS keeps tighter hold of the connection.

-- Robert

Reply to
Robert Redelmeier

SW is generally written in layers. Reduces complexity in each layer, increases reliablity and all those good things. systems that offer memory protection in which each application resides in its own virtual address space is also good, apps dont go about corrupting each others memory spaces. All this comes that a price, when data is to be sent from application to an application , the O.S which has access to both the applications memory space .. needs to be invoked to do the copy. (There are shortcuts ofcourse, applications can be designed to share some of their memory space). In a typical workstation you would have several applications that talk to maybe a few network stacks which in turn talk to atleast a few network drivers. If you shared chunks of memory between all of them, debugging a memory corruption would be painful and very time consuming. Issues that some companies have spent several 100 million $s combating. In general purpose OSes you have the drivers allocate some memory thats given to the networking chips, the chips use dma to get data in and out of the system. The driver invokes the os to copy this memory to the network stack, which invokes the os to copy data to the application.

all parts of this process can be optimized. If you are a router and are doing routing in SW, speed would be paramount. you would probably make the packet memory shared across all layers and not invoke the OS. also you might use fast/expensive packet memory and slow memory for everything else. Or if you are box with a fair degree of networking happening but are still a general purpose system.. you would share memory across the drivers and the network stack and take the hit of getting the O.S to copy to application space. you traded some reliability and ability to debug the system for some gains in speed. (e.g I think Windows and linux have drivers in the kernel space )

and if networking isnt really critical in your space, well who cares about a few copies. reliability and ability to debug the system become more important.

so the problem isnt that its difficult to implement.. its just that you chose what evil you want to live with.

Reply to
nkarkhan

Only as long as your NIC does not support interrupt coalescence or Large Send Offload - which every gigabit NIC worth its name should support nowdays.

Reply to
Denis Jedig

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.