Date: Fri, 27 Sep 2013 06:10:56 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: Takuya ASADA <syuu@dokukino.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, hiren panchasara <hiren.panchasara@gmail.com> Subject: Re: Adding Flow Director sysctls to ixgbe(4) Message-ID: <CAJ-Vmon57knybuNnSgah8ay7zKVen0YpW663wbYkWdh2gyTsDQ@mail.gmail.com> In-Reply-To: <52455949.5070501@freebsd.org> References: <CALCpEUHcpoJoo_gqjyDzosE1bJ_J=o3uqUuyYJA8dWZdjMrNTA@mail.gmail.com> <CALG4x-UTpAKPs5VKAyqyFgSAHcCFAMtMjOUJJoYAaYQ1dW4pqA@mail.gmail.com> <CAJ-VmomUZ9cXBx2fJL9e6s73uR_XLSUWS_rj7ZLZ0Pey119i5Q@mail.gmail.com> <52455949.5070501@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 September 2013 03:09, Julian Elischer <julian@freebsd.org> wrote: > On 9/27/13 4:53 PM, Adrian Chadd wrote: > >> I don't care about whether there's a generic API right now. I'd rather see >> it done as a staged thing, but _not_ sysctls. >> >> Having sysctls to add/remove entries from things is just plain evil. >> >> I'd rather instead come up with a device specific ioctl API for this for >> now w/ a userland tool for each particular chip. Then once we all get a >> bit >> more experience doing this, a unified API can be proposed. >> > > that makes it worse > If you want to put a device specific sysctl/ioctl set out there then have > a device INDEPENDENT > tool that knows how to handle the devices we have modified and when we > have enough examples we can change the > ioctl/sysctl interface to a generic one without changing the interface > people are using in their scripts. > I agree that's the eventual goal, sure. But there's not necessarily a clear-cut set of shared behaviour that a generic API could actually use. That's why I'm a fan of doing it in a couple of stages - get the device-specific stuff into the tree, get that stuff debugged, then sit down in the future and figure out what the sane intersection of this. The shared API may be partly "shared overlapping behaviour"and may partly be "have a capabilities api that defines which parts of the behaviour is supported by the NIC." Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon57knybuNnSgah8ay7zKVen0YpW663wbYkWdh2gyTsDQ>