Date: Wed, 29 Jun 2005 10:51:18 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Julian Elischer <julian@elischer.org> Cc: Max Laier <max@love2party.net>, Milan Obuch <net@dino.sk>, freebsd-net@freebsd.org Subject: Re: Julian's netowrking challenge 2005 Message-ID: <20050629085118.GD48704@obiwan.tataz.chchile.org> In-Reply-To: <42C1A204.1040504@elischer.org> References: <42C0DB3B.6000606@elischer.org> <200506281409.23885.max@love2party.net> <200506281415.36453.net@dino.sk> <200506281437.11835.max@love2party.net> <42C1A204.1040504@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julian, > We already chaned the mbuf from 128 to 256 bytes a while ago, so having > more in the > header is not necessarily a bad thing.. it generally wasn't a problem > when it was only > capable of holding 100 or so bytes of data. Even with an expanded header > we are still > talking of holding up to 200 or so bytes of data in the mbuf. > > I'd like to propose an expandable format for mbufs... > Pitty I'm about 25 years too late. > > [header1][total headerlength] > [offset to first tag] > [more header info] m_data-------\ > [tag1] [tag1 len] | > [tag1 data] | > [tag2] [tag2 len] | > [tag2 data] | > [end of header] | > ... | > packet data <-------------------/ > ... > [end of mbuf] I think I understand what you are proposing here, but what do you have in mind that would require such a system ? If there is no really good reason, I think it is wise to keep it simple. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050629085118.GD48704>