On 12/20/21 12:11 PM, Parav Pandit wrote:
>> After consideration, this future proofing seems like a good thing to have.
> Ok. I will first get kernel change merged, after which will send v3 for
> iproute2.
this set has been committed; not sure what happened to the notification
from patchworks
On 12/17/21 1:08 AM, Parav Pandit wrote:
> @@ -204,6 +217,8 @@ static void vdpa_opts_put(struct nlmsghdr *nlh, struct
> vdpa *vdpa)
> if (opts->present & VDPA_OPT_VDEV_MAC)
> mnl_attr_put(nlh, VDPA_ATTR_DEV_NET_CFG_MACADDR,
>sizeof(opts->mac),
On 12/1/21 9:22 PM, Parav Pandit wrote:
> @@ -233,6 +254,15 @@ static int vdpa_argv_parse(struct vdpa *vdpa, int argc,
> char **argv,
>
> NEXT_ARG_FWD();
> o_found |= VDPA_OPT_VDEV_MGMTDEV_HANDLE;
> + } else if ((matches(*argv, "mac") ==
On 12/1/21 9:22 PM, Parav Pandit wrote:
> @@ -154,6 +156,31 @@ static int vdpa_argv_mac(struct vdpa *vdpa, int argc,
> char **argv, char *mac)
> return 0;
> }
>
> +static int strtouint16_t(const char *str, uint16_t *p_val)
> +{
> + char *endptr;
> + unsigned long int val;
> +
> +
On 12/1/21 9:22 PM, Parav Pandit wrote:
> This series implements querying and setting of the mac address and mtu
> device config fields of the vdpa device of type net.
>
> An example of query and set as below.
>
> $ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
>
> $
On 11/30/21 10:07 AM, Jakub Kicinski wrote:
> On Tue, 30 Nov 2021 17:17:24 +0100 Toke Høiland-Jørgensen wrote:
>>> 1. Channels vs queues vs global.
>>>
>>> Jakub: no per-channel.
>>> David (Ahern): it's worth it to separate as Rx/Tx.
>>> Toke is fi
On 11/30/21 8:56 AM, Alexander Lobakin wrote:
> Rest:
> - don't create a separate `ip` command and report under `-s`;
Reporting XDP stats under 'ip -s' is not going to be scalable from a
readability perspective.
ifstat (misc/ifstat.c) has support for extended stats which is where you
are adding
On 11/30/21 10:04 AM, Jakub Kicinski wrote:
> On Tue, 30 Nov 2021 17:34:54 +0100 Alexander Lobakin wrote:
>>> Another thought on this patch: with individual attributes you could save
>>> some overhead by not sending 0 counters to userspace. e.g., define a
>>> helper that does:
>>
>> I know about
On 11/23/21 9:39 AM, Alexander Lobakin wrote:
> +static bool rtnl_get_xdp_stats_xdpxsk(struct sk_buff *skb, u32 ch,
> + const void *attr_data)
> +{
> + const struct ifla_xdp_stats *xstats = attr_data;
> +
> + xstats += ch;
> +
> + if
On 11/23/21 9:39 AM, Alexander Lobakin wrote:
> This is an almost complete rework of [0].
>
> This series introduces generic XDP statistics infra based on rtnl
> xstats (Ethtool standard stats previously), and wires up the drivers
> which collect appropriate statistics to this new interface.
On 8/4/21 12:27 PM, Saeed Mahameed wrote:
>
>> I just ran some quick tests with my setup and measured about 1.2%
>> worst
>
> 1.2% is a lot ! what was the test ? what is the change ?
I did say "quick test ... not exhaustive" and it was definitely
eyeballing a pps change over a small time
On 8/4/21 10:44 AM, Jakub Kicinski wrote:
> On Wed, 4 Aug 2021 10:17:56 -0600 David Ahern wrote:
>> On 8/4/21 6:36 AM, Jakub Kicinski wrote:
>>>> XDP is going to always be eBPF based ! why not just report such stats
>>>> to a special BPF_MAP ? BPF stack can
On 8/4/21 6:36 AM, Jakub Kicinski wrote:
>> XDP is going to always be eBPF based ! why not just report such stats
>> to a special BPF_MAP ? BPF stack can collect the stats from the driver
>> and report them to this special MAP upon user request.
> Do you mean replacing the ethtool-netlink /
On 4/16/21 2:16 AM, Xuan Zhuo wrote:
> In page_to_skb(), if we have enough tailroom to save skb_shared_info, we
> can use build_skb to create skb directly. No need to alloc for
> additional space. And it can save a 'frags slot', which is very friendly
> to GRO.
>
> Here, if the payload of the
ed, 3 insertions(+)
>
Reviewed-by: David Ahern
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 3/8/21 9:26 AM, Balazs Nemeth wrote:
> On Mon, 2021-03-08 at 09:17 -0700, David Ahern wrote:
>> On 3/8/21 9:07 AM, Willem de Bruijn wrote:
>>>> diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
>>>> index b1690149b6fa..cc1b6457fc93 100644
>>>>
On 3/8/21 9:07 AM, Willem de Bruijn wrote:
>> diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
>> index b1690149b6fa..cc1b6457fc93 100644
>> --- a/net/mpls/mpls_gso.c
>> +++ b/net/mpls/mpls_gso.c
>> @@ -27,7 +27,7 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff
>> *skb,
>>
>>
On 2/10/21 11:34 AM, Parav Pandit wrote:
> Linux vdpa interface allows vdpa device management functionality.
> This includes adding, removing, querying vdpa devices.
>
> vdpa interface also includes showing supported management devices
> which support such operations.
>
> This patchset includes
On 2/5/21 11:10 AM, Parav Pandit wrote:
> diff --git a/vdpa/include/uapi/linux/vdpa.h b/vdpa/include/uapi/linux/vdpa.h
> new file mode 100644
> index ..66a41e4e
> --- /dev/null
> +++ b/vdpa/include/uapi/linux/vdpa.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH
On 2/2/21 3:35 AM, Parav Pandit wrote:
> Add kernel headers to commit from kernel tree [1].
>79991caf5202c7 ("vdpa_sim_net: Add support for user supported devices")
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git branch:
> linux-next
>
Thinking about this flow a bit
Looks fine. A few comments below around code re-use.
On 1/22/21 4:26 AM, Parav Pandit wrote:
> diff --git a/vdpa/vdpa.c b/vdpa/vdpa.c
> new file mode 100644
> index ..942524b7
> --- /dev/null
> +++ b/vdpa/vdpa.c
> @@ -0,0 +1,828 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include
On 11/26/20 8:53 PM, Jason Wang wrote:
> 1. Where does userspace vdpa tool reside which users can use?
> Ans: vdpa tool can possibly reside in iproute2 [1] as it enables user to
> create vdpa net devices.
iproute2 package is fine with us, but there are some expectations:
syntax, command options
On 6/20/19 2:42 PM, Toke Høiland-Jørgensen wrote:
>>> I don't recall seeing any follow-up on this. Did you have a chance to
>>> formulate your ideas? :)
>>>
>>
>> Not yet. Almost done with the nexthop changes. Once that is out of the
>> way I can come back to this.
>
> Ping? :)
>
Definitely
On 4/18/19 8:24 AM, Toke Høiland-Jørgensen wrote:
>>>
>>
>> Understood. Hopefully in March I will get some time to come back to this
>> and propose an idea on what I would like to see - namely, the admin has
>> a config option at load time to enable driver counters versus custom map
>> counters.
24 matches
Mail list logo
