RE: [RFC V3 PATCH 03/26] net/netpolicy: get device queue irq information

> On Tue, Sep 13, 2016 at 5:23 AM, Liang, Kan <kan.li...@intel.com> wrote: > >> > >> Hello. > >> > >> On 09/12/2016 05:55 PM, kan.li...@intel.com wrote: > >> > >> > From: Kan Liang <kan.li...@intel.com> > >

RE: [RFC V3 PATCH 18/26] net/netpolicy: set tx queues according to policy

> -Original Message- > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Monday, September 12, 2016 4:23 PM > To: Liang, Kan <kan.li...@intel.com> > Cc: David S. Miller <da...@davemloft.net>; LKML ker...@vger.kernel.org>; Linux Kernel Network Develo

RE: [RFC V3 PATCH 03/26] net/netpolicy: get device queue irq information

> > Hello. > > On 09/12/2016 05:55 PM, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > Net policy needs to know device information. Currently, it's enough to > > only get irq information of rx and tx queues. > > > > This patch introduces ndo ops to do so, not

RE: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue

> > On Thu, Aug 4, 2016 at 12:36 PM, wrote: > > From: Kan Liang > > > > To achieve better network performance, the key step is to distribute > > the packets to dedicated queues according to policy and system run > > time status. > > > > This patch

RE: [RFC V2 PATCH 00/25] Kernel NET policy

> > > 5. Why disable IRQ balance? > > A: Disabling IRQ balance is a common way (recommend way for some > devices) to > >tune network performance. > > I appreciate that network tuning is hard, most people get it wrong, and > nobody agrees on the right answer. > > So rather than

RE: [RFC] ethtool bandwidth per-queue commands

> > Hi everyone. > > The ethtool interface has ETHTOOL_PERQUEUE command that is used to > read/set per-queue parameters for multiqueue Ethernet devices. > > I want to apply additional per-queue commands like per-queue bandwidth > and per-queue number of descriptors (like number of rings). >

RE: [RFC PATCH 00/30] Kernel NET policy

> > Yes, rtnl will bring some overheads. But the configuration is one time > > thing for application or socket. It only happens on receiving first > > packet. > > Thanks for destroying our connection rates. > > This kind of overhead is simply unacceptable. If so, I think I can make the

RE: [RFC PATCH 00/30] Kernel NET policy

> > > Also of course it would be fundamentally less efficient than kernel > > code doing that, just because of the additional context switches > > needed. > > Synchronizing or configuring any kind of queues already requires rtnl_mutex. > I didn't test it but acquiring rtnl mutex in

RE: [RFC PATCH 00/30] Kernel NET policy

> >> > >> On Mon, Jul 18, 2016 at 8:45 AM, Andi Kleen wrote: > >> >> It seems strange to me to add such policies to the kernel. > >> >> Addmittingly, documentation of some settings is non-existent and > >> >> one needs various different tools to set this (sysctl, procfs,

RE: [RFC PATCH 00/30] Kernel NET policy

> > On Mon, Jul 18, 2016 at 8:45 AM, Andi Kleen wrote: > >> It seems strange to me to add such policies to the kernel. > >> Addmittingly, documentation of some settings is non-existent and one > >> needs various different tools to set this (sysctl, procfs, sysfs, ethtool,

RE: [RFC PATCH 00/30] Kernel NET policy

> On Sun, Jul 17, 2016 at 11:55 PM, wrote: > > From: Kan Liang > > > > It is a big challenge to get good network performance. First, the > > network performance is not good with default system settings. Second, > > it is too difficult to do automatic

RE: [RFC PATCH 00/30] Kernel NET policy

> > Hi Kan, > > On 07/18/2016 08:55 AM, kan.li...@intel.com wrote: > > From: Kan Liang > > > > It is a big challenge to get good network performance. First, the > > network performance is not good with default system settings. Second, > > it is too difficult to do

RE: [RFC PATCH 00/30] Kernel NET policy

> On Mon, Jul 18, 2016 at 5:51 PM, Liang, Kan <kan.li...@intel.com> wrote: > > > > > >> > > >> > It is a big challenge to get good network performance. First, the > >> > network performance is not good with default system settings.

RE: [RFC PATCH 00/30] Kernel NET policy

> > > > It seems strange to me to add such policies to the kernel. > > > > But kernel is the only place which can merge all user's requests. > > I don't think so. > > If different requests conflict in a way that is possible to dosomething > meaningful the I don't see why userspace tool cannot

RE: [RFC PATCH 00/30] Kernel NET policy

> > > > It is a big challenge to get good network performance. First, the > > network performance is not good with default system settings. Second, > > it is too difficult to do automatic tuning for all possible workloads, > > since workloads have different requirements. Some workloads may want

RE: [PATCH V6 2/8] test_bitmap: unit tests for lib/bitmap.c

> > From: Kan Liang > Date: Tue, 16 Feb 2016 07:32:38 -0500 > > > @@ -43,6 +43,7 @@ obj-$(CONFIG_TEST_USER_COPY) += > test_user_copy.o > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o > >

RE: [RFC 3/5] net/ethtool: support set coalesce per queue

> On Thu, 2015-12-17 at 06:51 +, kan.li...@intel.com wrote: > [...] > > --- a/net/core/ethtool.c > > +++ b/net/core/ethtool.c > > @@ -1778,6 +1778,37 @@ static int > ethtool_get_per_queue_coalesce(struct net_device *dev, > >   return 0; > >  } > > > > +static int

RE: [RFC 2/5] net/ethtool: support get coalesce per queue

> On Thu, 2015-12-17 at 06:51 +, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Device driver has to provide an interface to get per queue coalesce. > > The interrupt coalescing parameters of each masked queue will be > > copied back to user space one by one. >

RE: [RFC 1/5] net/ethtool: introduce a new ioctl for per queue setting

> > +#define MAX_QUEUE 4096 > > +#define MAX_QUEUE_MASK (MAX_QUEUE / 64) > > + > > +/** > > + * struct ethtool_per_queue_op - apply sub command to the queues in > mask. > > + * @cmd: ETHTOOL_PERQUEUE > > + * @queue_mask: Mask the queues which sub command apply to > > + *

RE: [RFC 5/5] i40e/ethtool: support coalesce setting by queue

> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c > > b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c > > index b41f0be..5a35fdb 100644 > > --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c > > +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c > > @@ -1901,14 +1901,29 @@

RE: [RFC 1/2] net/ethtool: Add new coalescing parameter for queue

> On 07/12/15 20:42, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Intrdouce "queue" option for coalesce getting and setting. > > For coalesce getting, only the coalescing parameters from specific > > queue will be passed to user space. > > For coalesce setting,

RE: [RFC 1/2] net/ethtool: Add new coalescing parameter for queue

> > For that matter, if you've set different coalesce values on various queues, > what does asking for '-1' or "all the queues" mean and how should it return > info? Shouldn't all the specific queues be shown? Or do we now have to > do an ethtool command for each and every queue? > The only

RE: [RFC 1/2] net/ethtool: Add new coalescing parameter for queue

> > On Tue, 2015-12-08 at 10:02 -0800, Shannon Nelson wrote: > > On Mon, Dec 7, 2015 at 8:42 PM,   wrote: > > > From: Kan Liang > > > > > > Intrdouce "queue" option for coalesce getting and setting. > [...] > > > --- a/net/core/ethtool.c > > > +++