Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Feb 2013 14:11:52 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Randall Stewart <rrs@lakerest.net>
Cc:        freebsd-net@freebsd.org, Robert Watson <rwatson@freebsd.org>, Jack Vogel <jfvogel@gmail.com>, Kip Macy <kmacy@freebsd.org>
Subject:   Re: Driver patch to look at...
Message-ID:  <201302051411.52495.jhb@freebsd.org>
In-Reply-To: <00075DDD-73A1-4CA4-9574-036D43B071D9@lakerest.net>
References:  <D3AA078A-CD19-4228-A019-BE9C985895E2@lakerest.net> <990BD290-643B-4BC7-8D64-6D4CE987025A@lakerest.net> <00075DDD-73A1-4CA4-9574-036D43B071D9@lakerest.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, February 05, 2013 2:08:15 pm Randall Stewart wrote:
> Hmm
>=20
> wait, I could probably do the compare to whats in the ring buffer ;-D

I wouldn't bother.  The compare and branch is probably more expensive than
the store.

> R
> On Feb 5, 2013, at 2:04 PM, Randall Stewart wrote:
>=20
> > Hmm
> >=20
> > That would trade off a stack pointer + a compare
> > vs always doing the move.
> >=20
> > Thats fine until I have to add the _mc() version, then the put
> > back would be an atomic, and most of the time the return from
> > this is probably not changed=85
> >=20
> > I really would prefer not to since the compare and maybe store vs
> > the always store.. though the same now, would be far more expensive
> > in the _mc version.. if we do a _mc version of course ;-)
> >=20
> > But I am willing to do whatever .. since this really needs to be fixed.
> >=20
> > R
> > On Feb 5, 2013, at 1:52 PM, John Baldwin wrote:
> >=20
> >> On Tuesday, February 05, 2013 12:44:01 pm Randall Stewart wrote:
> >>> Actually, no it is used.
> >>>=20
> >>> If you look in if_var.h int he drbr_putback() function, it does
> >>> a buf_ring_swap when the old mbuf pointer does not equal the
> >>> new mbuf pointer. This *does* happen, I crashed at least once
> >>> yesterday when the igb driver did something to free the original
> >>> mbuf and return a new mbuf with the data (prepend or some such).
> >>>=20
> >>> I also have found several issues that I have fixed this morning.. its=
 been
> >>> crash city on my test beds..
> >>>=20
> >>> Here is the latest patch with all fixes and suggested changes from em=
aste=20
> >> (thanks Ed)
> >>=20
> >> Actually, one more suggestion then (since you have to keep putback).  =
It
> >> would be nice to not have to require 'snext' in all the callers.  How
> >> about replace buf_ring_swap() with a buf_ring_putback_sc() that accept=
s the
> >> mbuf and just stores it at the head unconditionally and have drbr_putb=
ack()
> >> use that?
> >>=20
> >> --=20
> >> John Baldwin
> >> _______________________________________________
> >> freebsd-net@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> >>=20
> >=20
> > ------------------------------
> > Randall Stewart
> > 803-317-4952 (cell)
> >=20
> > _______________________________________________
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> >=20
>=20
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
>=20
>=20

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302051411.52495.jhb>