--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 20, 2005 at 06:21:25PM +0100, Jaromir Dolecek wrote:
>=20
> Having m_defrag() free the old mbuf chain is usage convenience - the
> old mbuf chain would not be used anymore, the driver would free it
> otherwise anyway.

I think it'd be better to just return the chain. While you're right that=20
chances are we will just drop the packet, I think there are times we may=20
want to do something different with it. Yes, that would be using this=20
routine for something other than fixing up DMA segments... If we always=20
free the chain on error, it'd be very hard to support doing something with=
=20
the chain.

> > What would be potential reason for such failure besides memory allocati=
on
> > problems?
>=20
> It does happen that a mbuf chain contains too many non-continuous
> segments. What is 'too many' depends on ethernet adapter, some of them
> have limits on how many DMA segments they can use for transmitted
> packets.

As noted in another note, I think the question is why would the compaction=
=20
fail... :-)

> The issue occurred for me many times when testing big transfer
> (500MB) over 100Mbit/s ethernet network at standard MTU using single
> stream. I observed more than 7 such segments for some packets.
>=20
> If such packet is ignored (rather then defragged and sent), the
> communication basically ceases - apparently the network stack would
> re-send the packet couple more times, but always in the same
> fragmented state. If NIC drops the packet again, no data is ever sent
> again on that connection.

I have observed this issue too. And a fix for all drivers would be nice.

Take care,

Bill

--1UWUbFP1cBYEclgG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCJS8oWz+3JHUci9cRAkdkAJ9F3EIA0rD5FOuwcOFZOighs3LFXwCgk840
pM5Uy2ZdaiPZwQF5nP9+sAc=
=PafK
-----END PGP SIGNATURE-----

--1UWUbFP1cBYEclgG--