From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 16:38:59 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D4BE1065698; Fri, 29 Aug 2008 16:38:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 55D318FC23; Fri, 29 Aug 2008 16:38:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 13F5F73098; Fri, 29 Aug 2008 18:41:45 +0200 (CEST) Date: Fri, 29 Aug 2008 18:41:45 +0200 From: Luigi Rizzo To: Sam Leffler Message-ID: <20080829164145.GA47030@onelab2.iet.unipi.it> References: <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B8248A.3060103@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: "Bjoern A. Zeeb" , gnn@freebsd.org, net@freebsd.org Subject: Re: Small patch to multicast code... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 16:38:59 -0000 On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: ... > >and to be more explicit - the result of m_pullup is that > >the number of bytes specified as m_pullup argument are in > >a private piece of memory -- the 'data' region within the mbuf -- so > >you can freely play with them without trouble. > > > >That is why i suggested to just increase the argument to m_pullup > >by the size of the udp header so one can overwrite the checksum > >within the mbuf without touching the shared part in the cluster > >(if any). > > > > Hmm, never considered the m_pullup guaranteed a private copy (but I see > it in the code). The original semantics were just that the data was > contiguous. funny, i thought the guarantee of a writable copy was also part of the original semantics :) cheers luigi