Frank,

Just wanted to point out that LSO is not a "one vendor solution".

LSO adoption in the industry started back in 1998, in early GbE days. At
present virtually all 10GbE or GbE NIC vendors and all Operating Systems
support LSO. 

Solaris LSO support was actually long overdue, but now it can leverage
hardware feature that is (and likely will be, for foreseeable future)
the only de-facto NIC standard for stateless tx pdu offload. 

Leonid


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:networking-
> [EMAIL PROTECTED] On Behalf Of Francesco DiMambro
> Sent: Friday, May 30, 2008 7:21 PM
> To: Yunsong (Roamer) Lu
> Cc: [email protected]; [EMAIL PROTECTED]
> Subject: Re: [networking-discuss] LRO Implementation.
> 
> Hi Roamer
>     What's the reasoning behind EOLing the MDT? Claiming support for
> LSO as the alternative is premature, given only one vendor claims
support
> for it now. I have support for LSO for TCP currently in the hardware
> but is limited to only 64K, likewise if UDP gets implemented in our
> firmware, (not available now). MDT is much better it has no such
> limitations and therefore yields better performance with what we have
> now, both in terms of existing hardware and version of Solaris.
>     Our next gen hardware will support larger LSO size but that's not
> going to be this year, or I expect the Solaris 11 release timeframe.
>     I would really appreciate that you could re-consider EOLing MDT
> at least until the UDP LSO support in our hardware overtakes the
> performance  benefit provided by MDT.
> 
>     Frank
> 
> Yunsong (Roamer) Lu wrote:
> > Frank,
> > The current LSO implementation in Solaris is only for TCP. MDT was
> > implemented with both TCP and UDP. But the plan is to implement UDP
> > LSO and to EOL MDT in the near future, so you may consider whether
to
> > support UDP LSO on your hardware.
> >
> > The software interface for UDP LSO will be similar to TCP LSO but
> > slightly different since IP fragmentation instead TCP segmentation
> > will be done by the hardware.
> >
> > Thanks,
> >
> > Roamer
> >
> >
> > Francesco DiMambro wrote:
> >> Hi Meem
> >>     I tried a dtrace probe  in my driver around the MDT tx, and
it's
> >> definitely being called during a quick 'netperf -t UDP_STREAM',
> >> test.
> >>
> >>   1  31510        sge_multidata_xmit:return
> >>   1  31509         sge_multidata_xmit:entry
> >>   1  31510        sge_multidata_xmit:return
> >>   1  31509         sge_multidata_xmit:entry
> >>   1  31510        sge_multidata_xmit:return
> >>   1  31509         sge_multidata_xmit:entry
> >>   1  31510        sge_multidata_xmit:return
> >>   1  31509         sge_multidata_xmit:entry
> >>   1  31510        sge_multidata_xmit:return
> >>
> >>     With that same test UDP can transmit at twice the perf of MDT
> >> off, not to bad at all. Since you mentioned the competition, of
course
> >> I need to ask more questions, does the Solaris UDP stack support
> >> LSO for UDP. I talked to the HW guys here and they say it can be
> >> done once we know the software interface, looking at the code the
> >> only parameters it gives the driver for LSO is a flag to say the
packet
> >> is LSO and the MSS. Is that the only software interface needed to
> >> do UDP LRO? Seems like it would be but I want to make sure.
> >>
> >>     cheers
> >>     Frank
> >> Peter Memishian wrote:
> >>>  >     LSO doesn't work as well as MDT, Also the hardware I'm
> >>> working with
> >>>  > has no UDP LSO capability, does any?
> >>>
> >>> I don't see any support in our UDP module for MDT.  Others more
> >>> familiar
> >>> with the latest hardware could speak to the UDP LSO question, but
I'd
> >>> heard rumors that some Neterion ASICs could do it.
> >>>
> >>> --
> >>> meem
> >>>
> >>
> >> _______________________________________________
> >> networking-discuss mailing list
> >> [email protected]
> >
> 
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to