svn commit: r280759 - head/sys/netinet

[John-Mark Gurney]

Slawa Olhovchenkov wrote this message on Sun, Mar 29, 2015 at 00:34 +0300:
> On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
> 
> > > On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote:
> > > J> Please read:
> > > J> https://tools.ietf.org/html/rfc6864
> > 
> > Anyways, are we really sending so many fragments that we are thrashing
> > the cache line?  I'd imagine a much lower hanging fruit is only provide
> > ip_id when a non-atomic packet is being sent...
> 
> In this case may be do range allocation of ID (per-CPU)?
> For example, allocate 128 ID, not one ID?

Do you mean what to do in the case of an atomic packet?

Per RFC:
   In atomic datagrams, the IPv4 ID field has no meaning; thus, it can
   be set to an arbitrary value, i.e., the requirement for non-repeating
   IDs within the source address/destination address/protocol tuple is
   no longer required for atomic datagrams:

You can just set it to 0, or any value we feel like.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."