Subject: RE: [rddp] Marker Interval

From: "Barron, Dwight" <[email-masked]>
Date: Mon, 24 Feb 2003 09:56:11 -0600

Assuming we had a large number of negotiable marker intervals, what would the optimum negotiation strategy be for a software-MPA to connect to a hardware-MPA implementation? Clearly, the SW-MPA would want larger intervals to minimize overhead, while presumably the HW-MPA would want smaller intervals to minimize buffering. While I see a lot of value in having mixed mode connections, I keep coming back the notion that the SW implementation is willingly taking on additional overhead for the benefit of the HW implementation, in which case the SW end would accept the HW's recommended marker interval value. 

Regards,
Dwight

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 24, 2003 8:30 AM
> To: [email-masked]
> Subject: [rddp] Marker Interval
> 
> 
> Somesh Gupta wrote:
> 
> > >As David pointed out, a smaller marker
> > >interval puts an unacceptable burden on a software client
> > >(I thing the example was of a 64KB read/write requiring
> > >140+ markers - each of which causes creation of that many
> > >segments, plus creating and inserting markers and marker
> > >vectors etc) - worse than simply using a NIC doing a large
> > >TCP send or TOE offload.
> 
> That's definitely a problem.
> 
> Caitlin Bestler wrote:
> 
> > The pattern where the true payload is a repeating pattern.
> > 140 markers does not require 140 distinct descriptors.
> > If you look up old mini-computers you'll find many examples
> > of repeating groups in DMA control.
> 
> That's mostly a statement about building new hardware.  A lot of
> existing DMA hardware, OS syscall interfaces, etc. don't support
> repeating descriptors.
> 
> Michael Krause wrote:
> 
> > The optimal design is a hardware implementation that 
> provides marker 
> > insertion / removal.  The objective is to insure that one 
> can implement
> > and interoperate with a software-based solution without creating a
> > complete performance nightmare but also with the 
> understanding that a
> > software-based solution will not perform as well as a hardware-based
> > solution.
> 
> The 512-byte fixed marker interval appears to have been over-optimized
> for optimal (new hardware) designs to the detriment of (re)use of
> existing software stacks.  The design rationale that I've seen based
> on minimum required IP payload sizes and the desire for a 
> "flow-through"
> implementation is not very convincing, especially as the current MPA
> design can't achieve "flow-through" due to the inability for 
> a receiver
> to determine whether an aligned stream will stay aligned (yes, one
> could build a "flow-through" implementation, but it will have 
> robustness
> problems  akin to a TCP implementation with inadequate buffering).  In
> addition, we can go back through the "there's no such thing 
> as a buffer-
> less [R]NIC discussion" if that's necessary, but more to the point is
> that the number of descriptors for reasonable-sized operations
> (e.g., 16 or more for a single 8KB transfer) is hard to justify.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Somesh Gupta" <[email-masked]>
Date: Mon, 24 Feb 2003 09:47:05 -0800

Dwight,

The point is of allowing the marker interval to be flexible
so that hardware implementations that want to work well with
software based senders may allow a larger marker interval
or not require it at all.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Barron, Dwight
> Sent: Monday, February 24, 2003 7:56 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [rddp] Marker Interval
> 
> 
> Assuming we had a large number of negotiable marker intervals, 
> what would the optimum negotiation strategy be for a software-MPA 
> to connect to a hardware-MPA implementation? Clearly, the SW-MPA 
> would want larger intervals to minimize overhead, while 
> presumably the HW-MPA would want smaller intervals to minimize 
> buffering. While I see a lot of value in having mixed mode 
> connections, I keep coming back the notion that the SW 
> implementation is willingly taking on additional overhead for the 
> benefit of the HW implementation, in which case the SW end would 
> accept the HW's recommended marker interval value. 
> 
> Regards,
> Dwight
>