> On Tue, Sep 13, 2016 at 5:23 AM, Liang, Kan wrote:
> >>
> >> Hello.
> >>
> >> On 09/12/2016 05:55 PM, kan.li...@intel.com wrote:
> >>
> >> > From: Kan Liang
> >> >
> >> > Net policy needs to know device
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Monday, September 12, 2016 4:23 PM
> To: Liang, Kan
> Cc: David S. Miller ; LKML ker...@vger.kernel.org>; Linux Kernel Network Developers
> ; Kirsher, Jeffrey T ;
> Ingo Molnar ; pet.
>
> 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 ethtool ops.
> > Because t
>
> 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 provides an interface which can return the pr
>
> > 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 fix
>
> 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).
>
>
> > 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 configu
>
> > 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 inet_recvmsg
> >>
> >> 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, etc).
>
> 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,
> >> etc).
> >
> > Th
> 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 tuning for all possible workloads,
> > sinc
>
> 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 automatic tuning for all poss
> On Mon, Jul 18, 2016 at 5:51 PM, Liang, Kan wrote:
> >
> >
> >> >
> >> > It is a big challenge to get good network performance. First, the
> >> > network performance is not good with default system settings.
> >> > Seco
>
> > > 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
> >
> > 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
>
>
> 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
> > obj-$(CONFIG_TEST_PRINTF) += test_pr
> 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 ethtool_set_per_queue_coale
> 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.
> >
> > Signed-off-by: K
> > +#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
> > + * @sub
> > 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 @@ stat
>
> 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
> > > +++ b/net/core/ethtool.c
> > > @@ -1123,10 +1123,16
> 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, the coalescing parameter
>
> 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 w
23 matches
Mail list logo
