Hi Ian-
I'm very impressed and interested in the work that you
guys have done. I've been working with a protocol called
Scheduled Transfers (ST) and doing some work similar
to what you guys have done using the alteon GbE card
on linux platforms.
You can look at http://oss.sgi.com/projects/stp to get
more information regarding ST.
I'm particularly impressed by the UDP payload throughput
of 956Mb/s for 1480 bytes. In my experience I found the
alteon firmware loop times to be closer to 12-16us for
1500byte frames. Did you guys do the firmware from scratch?
The second question I had was: how easy/difficult is to run
a different protocol (stack) using the modified firmware
by you guys.
thanks,
:a
Ian Pratt wrote:
>
> > I believe that Ian Pratt did something along these lines for a project at
> > the University of Cambridge. He may have some specific insights with this.
> > I am not sure whether he did this work in the context of Linux, but I do
> > know that he did this for another OS (Nemisis) that was developed at the U.
> > of Cambridge.
>
> Sorry to take sooo long to reply to this.
>
> We developed some new firmware for the Alteon NIC last year, and
> wrote appropriate Linux drivers and user-space protocol stacks.
>
> Our firmware has the following features:
> 32+ `virtual interfaces'
> each virtual interface has its own TX/RX descriptor rings
> applications register pages with OS for use for DMA
> early packet demultiplex using packet filters uploaded by OS
> RX packet filter ensures correct header/payload split into user buffers
> transmit packet filters for verifying application's packets before TX
> TX traffic shaping with token buckets and round-robin MUX'ing
>
> We then integrated the `user-accessible' network access into
> Linux, enabling applications to use protocol stacks implemented
> in shared-libraries (we ported Linux's TCP/UDP stacks to
> user-space to enable a fair performance comparison). The RX/TX
> packet filters and TX traffic shaping enable the operating system
> to remain in control of what packets an application is allowed to
> send and receive.
>
> Performance is good. We get 974Mb/s TCP payload data throughput
> with 8192 octet MSS, and 796Mb/s for 1472. UDP payload data
> throughput is 992Mb/s for 8192 MSS, 956Mb/s for
> 1480. Non-blocking app-to-app ping-pong latency is 45us.
>
> The following paper has more details:
> http://www.cl.cam.ac.uk/~iap10/gige.ps
>
> Hope this is useful,
> Ian
|