From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Mohammed Gamal <mmorsy@redhat.com>
Subject: Re: [PATCH net] hv_netvsc: preserve hw_features on mtu/channels/ringparam changes
Date: Tue, 14 Nov 2017 17:58:23 +0100 [thread overview]
Message-ID: <871sl0u79s.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20171114083457.5ec8c4f0@xeon-e3> (Stephen Hemminger's message of "Tue, 14 Nov 2017 08:34:57 -0800")
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Tue, 14 Nov 2017 16:22:05 +0100
> Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
> Yes, this looks like a real issue.
>
>> + /* Query hardware capabilities if we're called from netvsc_probe() */
>> + if (!net->hw_features) {
>> + ret = rndis_netdev_set_hwcaps(net_device, rndis_device);
>> + if (ret != 0)
>> + goto err_dev_remv;
>> + }
>> +
>
> Rather than conditional behavior in rndis_filter_device_add, it would be cleaner
> to make the call to get hardware capabilities there.
>
> Please respin and make the query of host a separate function.
You mean call rndis_netdev_set_hwcaps() from netvsc_probe()? Will do.
One question though: in case we'll be avoiding
rndis_filter_set_offload_params() call on mtu/channels/ringparam
changes -- can we trust the host to preserve what was there before the
RNDIS reset? In case not we'll have to untangle what is
rndis_netdev_set_hwcaps() in my patch splitting it into two: hw_features
setup and rndis_filter_set_offload_params() and leaving the later in
rndis_filter_device_add().
Thanks,
--
Vitaly
next prev parent reply other threads:[~2017-11-14 16:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-14 15:22 [PATCH net] hv_netvsc: preserve hw_features on mtu/channels/ringparam changes Vitaly Kuznetsov
2017-11-14 16:34 ` Stephen Hemminger
2017-11-14 16:58 ` Vitaly Kuznetsov [this message]
2017-11-14 21:48 ` Haiyang Zhang
2017-11-15 9:42 ` Vitaly Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871sl0u79s.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mmorsy@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=sthemmin@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.