[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bff99f2f-8293-0dda-1db1-881e555f3623@redhat.com>
Date: Mon, 9 Jan 2017 10:39:55 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
kvm@...r.kernel.org, stephen@...workplumber.org, wexu@...hat.com,
stefanha@...hat.com
Subject: Re: [PATCH V4 net-next 3/3] tun: rx batching
On 2017年01月07日 03:47, Michael S. Tsirkin wrote:
>> +static int tun_get_coalesce(struct net_device *dev,
>> + struct ethtool_coalesce *ec)
>> +{
>> + struct tun_struct *tun = netdev_priv(dev);
>> +
>> + ec->rx_max_coalesced_frames = tun->rx_batched;
>> +
>> + return 0;
>> +}
>> +
>> +static int tun_set_coalesce(struct net_device *dev,
>> + struct ethtool_coalesce *ec)
>> +{
>> + struct tun_struct *tun = netdev_priv(dev);
>> +
>> + if (ec->rx_max_coalesced_frames > NAPI_POLL_WEIGHT)
>> + return -EINVAL;
> So what should userspace do? Keep trying until it succeeds?
> I think it's better to just use NAPI_POLL_WEIGHT instead and DTRT here.
>
Well, looking at how set_coalesce is implemented in other drivers,
-EINVAL is usually used when user give a value that exceeds the
limitation. For tuntap, what missed here is probably just a
documentation for coalescing in tuntap.txt. (Or extend ethtool to return
the max value). This seems much better than silently reduce the value to
the limitation.
Thanks
Powered by blists - more mailing lists