On Tue, May 05, 2015 at 05:32:11AM -0400, John Baldwin wrote:
J> > On Mon, May 04, 2015 at 04:01:28PM -0400, John Baldwin wrote:
J> > J> > Your answer seems quite orthogonal to my question. I reread it couple
of times,
J> > J> > but still can't figure out how exactly do you prefet to fetch
per-queue stats.
J> > J> > Can you please explain in more detail?
J> > J>
J> > J> struct if_queue {
J> > J> struct ifnet *ifq_parent;
J> > J> void (*ifq_get_counter)(struct if_queue *, ift_counter);
J> > J> ...
J> > J> };
J> > J>
J> > J> (Pretend that if_queue is a new object type and that each RX or TX
queue on a
J> > J> NIC has one.)
J> >
J> > This looks like a driver with 1024 queues would carry extra 1024 function
pointers
J> > per ifnet. Is it really worth? Could it be that queue #0 differs from
queue #1?
J> > Even, if a rare case when queue #N differs from queue #M do exist, they
still
J> > can share the pointer and the differentiating logic would be in the
function
J> > itself.
J>
J> Drivers with 1024 queues already have several pointers, however, you could
J> have a "class" pointer (something ifnet doesn't have) like 'cdevsw' where you
J> have a single structure containing the ops and the various queues have a
pointer
J> to that instead of having N duplicated function pointers. OTOH, you could
probably
J> keep this as an ifnet op, but accept a queue pointer as the argument still
(that
J> would give a similar effect).
J>
J> If you really want to trim function pointers though, fix ifnet to not
duplicate
J> them and use a shared ifnetsw among instances. :)
Note that my own paragraph quoted below states that this is exactly what I did
in projects/ifnet.
J> > Right now, in the projects/ifnet branch, I'm developing in quite opposite
J> > direction - many instances of the same driver share the set of interface
J> > options. This is done to shrink struct ifnet.
J> >
J> > What's wrong with KPI when the queue number is parameter to an ifop? This
J> > KPI would also hide the queue pointers from the stack, which are quite
J> > driver specific.
J>
J> I think at some point we will want stack awareness in the stack for more than
J> just stats. For example, the whole buf_ring/if_transmit thing has been
non-ideal
J> in terms of requiring drivers to duplicate a lot of code that was previously
J> hidden from them making the drivers more complex (and fragile). Several of
us
J> would like to push the knowledge of the software ring (which is per-TX queue)
J> back up out of drivers, but that will require some per-queue state stored
outside
J> of drivers. You could certainly do that with parallel arrays instead, but
I'm
J> not sure that is better than having a structure (at least I'm not sure that
is
J> as easy to reason about when you are working on the stack)
Well, if the drivers access the structure functionally: dequeue, putback, etc.,
then this isn't a big deal.
When the structure is ready, and we got drivers capable of working with it,
we can introduce if_transmit_queue. I hope by that time projects/ifnet will
be finalized, and expanding functionality of ifnet will be much easier.
--
Totus tuus, Glebius.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
