Date: Thu, 8 Nov 2012 15:32:59 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: pyunyh@gmail.com, FreeBSD Net <freebsd-net@freebsd.org>, Pyun YongHyeon <yongari@freebsd.org> Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti Message-ID: <CAJ-Vmo=QuP1s=ppnp2u%2BVpuJRbncaHLwi_0ku5=dr9%2BReYp79w@mail.gmail.com> In-Reply-To: <509BC2E2.4030907@freebsd.org> References: <201211080206.qA826RiN054539@svn.freebsd.org> <CAJ-VmomEOPGbLwmOmL0EdenZA7QKbV5P-hAYsTRcwLao2LbAqg@mail.gmail.com> <20121108023858.GA3127@michelle.cdnetworks.com> <CAJ-Vmoma1DJRT8_ezdEpVYrZXak%2B2B4mBHAPxhoUKr0nUrO6YQ@mail.gmail.com> <509BC2E2.4030907@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On 8 November 2012 06:34, Andre Oppermann <andre@freebsd.org> wrote: > TCP/UDP doesn't (want to) generate any fragments at all and tries > to avoid it at almost all cost. We want to send very large packets > and have the NIC fragment/segment it (TSO/UDP frag offload). What about if it's a router and the frames don't have DF set? Not that it should happen often, however.. > >> We could create a device or interface flag that indicates whether the >> driver can handle multiple mbufs chained via m_nextpkt through >> if_transmit(), and then teach one or two drivers that particular >> logic. > > > Agreed. I think that's the way to go. It must be very well specified > in semantics though. Otherwise it's just too easy to leak mbuf all > over the place. I mentioned this to Robert Watson today at the FreeBSD vendor summit and he said much the same thing about testing and assertions. Adrianhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=QuP1s=ppnp2u%2BVpuJRbncaHLwi_0ku5=dr9%2BReYp79w>