* Re: [Open-FCoE] [PATCH RFC 2/5] qedf: Add QLogic FastLinQ offload FCoE driver framework.
From: Hannes Reinecke @ 2017-01-10 6:56 UTC (permalink / raw)
To: Chad Dupuis
Cc: martin.petersen, fcoe-devel, netdev, QLogic-Storage-Upstream,
linux-scsi, yuval.mintz
In-Reply-To: <alpine.OSX.2.00.1701091141550.1044@administrators-macbook-pro.local>
On 01/09/2017 05:45 PM, Chad Dupuis wrote:
>
> On Wed, 28 Dec 2016, 9:00am -0000, Hannes Reinecke wrote:
>
>> On 12/23/2016 08:17 PM, Dupuis, Chad wrote:
>>> From: "Dupuis, Chad" <chad.dupuis@cavium.com>
>>>
>>> The QLogic FastLinQ Driver for FCoE (qedf) is the FCoE specific module
>>> for 41000 Series Converged Network Adapters by QLogic.
>>>
>>> This patch consists of following changes:
>>> - MAINTAINERS Makefile and Kconfig changes for qedf
>>> - PCI driver registration
>>> - libfc/fcoe host level initialization
>>> - SCSI host template initialization and callbacks
>>> - Debugfs and log level infrastructure
>>> - Link handling
>>> - Firmware interface structures
>>> - QED core module initialization
>>> - Light L2 interface callbacks
>>>
>>> Signed-off-by: Nilesh Javali <nilesh.javali@cavium.com>
>>> Signed-off-by: Manish Rangankar <manish.rangankar@cavium.com>
>>> Signed-off-by: Saurav Kashyap <saurav.kashyap@cavium.com>
>>> Signed-off-by: Chad Dupuis <chad.dupuis@cavium.com>
>>> ---
>>> MAINTAINERS | 6 +
>>> drivers/scsi/Kconfig | 1 +
>>> drivers/scsi/qedf/Kconfig | 11 +
>>> drivers/scsi/qedf/Makefile | 5 +
>>> drivers/scsi/qedf/qedf.h | 555 ++++++
>>> drivers/scsi/qedf/qedf_attr.c | 165 ++
>>> drivers/scsi/qedf/qedf_dbg.c | 192 +++
>>> drivers/scsi/qedf/qedf_dbg.h | 153 ++
>>> drivers/scsi/qedf/qedf_debugfs.c | 472 +++++
>>> drivers/scsi/qedf/qedf_main.c | 3519 ++++++++++++++++++++++++++++++++++++++
>>> drivers/scsi/qedf/qedf_version.h | 15 +
>>> 11 files changed, 5094 insertions(+)
>>> create mode 100644 drivers/scsi/qedf/Kconfig
>>> create mode 100644 drivers/scsi/qedf/Makefile
>>> create mode 100644 drivers/scsi/qedf/qedf.h
>>> create mode 100644 drivers/scsi/qedf/qedf_attr.c
>>> create mode 100644 drivers/scsi/qedf/qedf_dbg.c
>>> create mode 100644 drivers/scsi/qedf/qedf_dbg.h
>>> create mode 100644 drivers/scsi/qedf/qedf_debugfs.c
>>> create mode 100644 drivers/scsi/qedf/qedf_main.c
>>> create mode 100644 drivers/scsi/qedf/qedf_version.h
>>>
>> [ .. ]
>>> +/* Returns true if we have a valid vlan, false otherwise */
>>> +static bool qedf_initiate_fipvlan_req(struct qedf_ctx *qedf)
>>> +{
>>> + int rc;
>>> +
>>> + if (atomic_read(&qedf->link_state) != QEDF_LINK_UP) {
>>> + QEDF_ERR(&(qedf->dbg_ctx), "Link not up.\n");
>>> + return false;
>>> + }
>>> +
>>> + while (qedf->fipvlan_retries--) {
>>> + if (qedf->vlan_id > 0)
>>> + return true;
>> Some weird FCoE bridges (most notably HP VirtualConnect) return a VLAN
>> ID of '0'. Shouldn't you rather test for '>= 0' here?
>
> Will look into this but isn't a VLAN ID of 0 not valid?
>
Well, a VLAN ID of '0' indicates no VLAN at all but rather use the base
interface.
But you still will be seeing a VLAN ID '0' in the FIP VLAN response.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [for-next V3 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Leon Romanovsky @ 2017-01-10 6:50 UTC (permalink / raw)
To: Doug Ledford
Cc: Saeed Mahameed, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Eli Cohen, Matan Barak
In-Reply-To: <1484024006.2149.11.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4474 bytes --]
On Mon, Jan 09, 2017 at 11:53:26PM -0500, Doug Ledford wrote:
> On Mon, 2017-01-09 at 21:00 +0200, Saeed Mahameed wrote:
> > Hi Dave and Doug,
> >
> > Following the mlx5-odp submission, you can find here the 2nd mlx5
> > submission for 4.11 as a pull-request including mlx5 4K UAR support
> > from
> > Eli Cohen (details below). For you Doug, this pull request will
> > provide
> > you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> > net-next mlx5-odp merge commit.
> >
> > v1->v2:
> > - Removed 64BIT arch dependency.
> > v2->v3:
> > - Removed extra space.
> >
> > Thank you,
> > Saeed.
> >
> > The following changes since commit
> > 525dfa2cdce4f5ab76251b5e57ebabf4f2dfc40c:
> >
> > Merge branch 'mlx5-odp' (2017-01-02 15:51:21 -0500)
>
> This base commit looks harmless enough, but since it's likely just a
> commit in your tree, it isn't really a clear indicator of how you set
> this tree up....
>
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
> > tags/mlx5-4kuar-for-4.11
> >
> > for you to fetch changes up to
> > f502d834950a28e02651bb7e2cc7111ddd352644:
> >
> > net/mlx5: Activate support for 4K UARs (2017-01-09 20:25:10 +0200)
>
> But once I pulled this, it became clear you guys based your tree on a
> net-next starting point. You need to make that clear in the beginning.
> And unless you can't avoid it, don't do it. I don't like having to
> pull in Dave's net-next before I pull your code because it means I
> can't submit my pull request to Linus during the merge window as a
> single pull request, I have to split it up to be the stuff that is
> based on net-next and the stuff based on my own next area.
>
> >
> > ----------------------------------------------------------------
> > Eli Cohen (10):
> > IB/mlx5: Fix kernel to user leak prevention logic
> > IB/mlx5: Fix error handling order in create_kernel_qp
> > mlx5: Fix naming convention with respect to UARs
> > IB/mlx5: Fix retrieval of index to first hi class bfreg
> > net/mlx5: Introduce blue flame register allocator
> > net/mlx5: Add interface to get reference to a UAR
> > IB/mlx5: Use blue flame register allocator in mlx5_ib
> > IB/mlx5: Allow future extension of libmlx5 input data
> > IB/mlx5: Support 4k UAR for libmlx5
> > net/mlx5: Activate support for 4K UARs
> >
> > drivers/infiniband/hw/mlx5/cq.c | 10 +-
> > drivers/infiniband/hw/mlx5/main.c | 278 ++++++++++-
> > -----
> > drivers/infiniband/hw/mlx5/mlx5_ib.h | 32 +-
> > drivers/infiniband/hw/mlx5/qp.c | 290 +++++++--
> > --------
> > drivers/net/ethernet/mellanox/mlx5/core/cq.c | 2 +
> > drivers/net/ethernet/mellanox/mlx5/core/en.h | 11 +-
> > .../net/ethernet/mellanox/mlx5/core/en_common.c | 12 +-
> > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +-
> > drivers/net/ethernet/mellanox/mlx5/core/eq.c | 14 +-
> > drivers/net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> > drivers/net/ethernet/mellanox/mlx5/core/uar.c | 351
> > +++++++++++++--------
> > include/linux/mlx5/cq.h | 5 +-
> > include/linux/mlx5/device.h | 23 +-
> > include/linux/mlx5/doorbell.h | 6 +-
> > include/linux/mlx5/driver.h | 81 ++---
> > include/linux/mlx5/mlx5_ifc.h | 7 +-
> > include/uapi/rdma/mlx5-abi.h | 19 +-
> > 17 files changed, 672 insertions(+), 516 deletions(-)
>
> Without going into excruciating detail, this is what I got when I
> pulled your branch:
>
> 273 files changed, 8891 insertions(+), 6637 deletions(-)
> create mode 100644 drivers/net/ethernet/qlogic/qede/qede_filter.c
> create mode 100644 drivers/net/ethernet/qlogic/qede/qede_fp.c
>
> Please don't do this unless you absolutely have to.
We will do our best to avoid such situations in the future.
This specific pull request was after our mistake with first pull
request, which was sent as a patch set, instead of pull request.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/13] net: ethernet: aquantia: Add ring support code
From: Stephen Hemminger @ 2017-01-10 6:34 UTC (permalink / raw)
To: Alexander Loktionov
Cc: netdev, David VomLehn, Simon Edelhaus, Dmitrii Tarakanov,
Pavel Belous
In-Reply-To: <6dfadde2e1fe39b46d814c83fb7460566e860095.1483999588.git.vomlehn@texas.net>
On Mon, 9 Jan 2017 14:16:01 -0800
Alexander Loktionov <Alexander.Loktionov@aquantia.com> wrote:
> ++self->stats.rx_packets;
> + ++ndev->stats.rx_packets;
> + ndev->stats.rx_bytes += buff->len;
Why keep two sets of statistics (self->stats and ndev->stats); seems redundant.
Could also use per-cpu network stats pcpu_sw_netstats
You could also optimize by doing only one addition of ndev->stats after processing
several packets.
> + skb = netdev_alloc_skb(ndev, ETH_HLEN);
> + skb_put(skb, ETH_HLEN);
> + memcpy(skb->data, page_address(buff->page), ETH_HLEN);
Why not use build_skb() here?
^ permalink raw reply
* pull-request: wireless-drivers 2017-01-10
From: Kalle Valo @ 2017-01-10 6:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's the pull request with the important rtlwifi fix, more info in the
tag below.
During the long weekend we had here I finally updated Ubuntu on my
workstation and git was updated along that. If you see anything funny or
problems in my pull request due to the upgrade, please let me know. The
upgrade might have broken something, at least git-request-pull needs to
be now called differently.
Kalle
The following changes since commit f5a0aab84b74de68523599817569c057c7ac1622:
net: ipv4: dst for local input routes should use l3mdev if relevant (2016-12-29 22:27:23 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-01-10
for you to fetch changes up to 60f59ce0278557f7896d5158ae6d12a4855a72cc:
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data (2016-12-30 15:38:13 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
Only two fixes at this time. The rtlwifi fix is an important one as it
fixes a reported oops and Linus was already asking about it. The
orinoco fix is not tested on a real device, because it's old legacy
hardware and hardly no-one use it, but it should fix a (theoretical)
issue with VMAP_STACK.
----------------------------------------------------------------
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Larry Finger (1):
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++++++++++++++----------
drivers/net/wireless/intersil/orinoco/mic.h | 3 +-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 +--
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
4 files changed, 31 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Rob Herring @ 2017-01-10 5:35 UTC (permalink / raw)
To: Russell King
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Marcin Wojtas, Sebastian Hesselbarth,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1cPpAk-0005uJ-TM-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Sat, Jan 07, 2017 at 11:28:30AM +0000, Russell King wrote:
> Correct the Marvell Orion MDIO binding document to properly reflect the
> cases where an interrupt is present. Augment the examples to show this.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
> .../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] vhost: scsi: constify target_core_fabric_ops structures
From: Michael S. Tsirkin @ 2017-01-10 5:11 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: kvm, netdev, linux-kernel, virtualization, julia.lawall
In-Reply-To: <1483975262-1260-1-git-send-email-bhumirks@gmail.com>
On Mon, Jan 09, 2017 at 08:51:02PM +0530, Bhumika Goyal wrote:
> Declare target_core_fabric_ops strucrues as const as they are only
> passed as an argument to the functions target_register_template and
> target_unregister_template. The arguments are of type const struct
> target_core_fabric_ops *, so target_core_fabric_ops structures having
> this property can be declared const.
> Done using Coccinelle:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct target_core_fabric_ops i@p={...};
>
> @ok@
> position p;
> identifier r.i;
> @@
> (
> target_register_template(&i@p)
> |
> target_unregister_template(&i@p)
> )
> @bad@
> position p!={r.p,ok.p};
> identifier r.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> +const
> struct target_core_fabric_ops i;
>
> File size before: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18063 2985 40 21088 5260 drivers/vhost/scsi.o
>
> File size after: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18479 2601 40 21120 5280 drivers/vhost/scsi.o
What are these numbers trying to prove?
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> drivers/vhost/scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 253310c..620366d 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2087,7 +2087,7 @@ static void vhost_scsi_drop_tport(struct se_wwn *wwn)
> NULL,
> };
>
> -static struct target_core_fabric_ops vhost_scsi_ops = {
> +static const struct target_core_fabric_ops vhost_scsi_ops = {
> .module = THIS_MODULE,
> .name = "vhost",
> .get_fabric_name = vhost_scsi_get_fabric_name,
If it can be const it probably should ...
> --
> 1.9.1
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 5:00 UTC (permalink / raw)
To: John Fastabend
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <58746247.604@gmail.com>
On Mon, Jan 09, 2017 at 08:25:43PM -0800, John Fastabend wrote:
> On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
> >> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
> >>>>
> >>>>
> >>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> >>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> >>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> >>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> >>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> >>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> >>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
> >>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
> >>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
> >>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
> >>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
> >>>>>>>>>>>>>>> program load and does not block MTU changes after the program
> >>>>>>>>>>>>>>> has loaded.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>>>>>>> ---
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> >>>>>>>>>>>>> needs to read the mtu via
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> virtio_cread16(vdev, ...)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> or we may break the negotiated mtu.
> >>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> >>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
> >>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
> >>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
> >>>>>>>>>>> notification if the MTU is negotiated.
> >>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
> >>>>>>>>>> MTU change in this case?
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>> Why does host care?
> >>>>>>>>>
> >>>>>>>> Well the guest will drop packets after mtu has been reduced.
> >>>>>>> I didn't know. What place in code does this?
> >>>>>>>
> >>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
> >>>>>> buffer sizes and a receive side max length filter. For example in the Intel
> >>>>>> drivers if a packet with length greater than MTU + some headroom is received we
> >>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
> >>>>>> virtio doesn't have any code to drop packets on rx size.
> >>>>>>
> >>>>>> In virtio I don't see any existing case currently. In the XDP case though we
> >>>>>> need to ensure packets fit in a page for the time being which is why I was
> >>>>>> looking at this code and generated this patch.
> >>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >>>>>
> >>>>>
> >>>>
> >>>> Does this work for small buffers consider it always allocate skb with size
> >>>> of GOOD_PACKET_LEN?
> >>>
> >>> Spec says hardware won't send in packets > max mtu in config space.
> >>>
> >>>> I think in any case, we should limit max_mtu to
> >>>> GOOD_PACKET_LEN for small buffers.
> >>>>
> >>>> Thanks
> >>>
> >>> XDP seems to have a bunch of weird restrictions, I just
> >>> do not like it that the logic spills out to all drivers.
> >>> What if someone decides to extend it to two pages in the future?
> >>> Recode it all in all drivers ...
> >>>
> >>> Why can't net core enforce mtu?
> >>>
> >>
> >> OK I agree I'll put most the logic in rtnetlink.c when the program is added
> >> or removed.
> >>
> >> But, I'm looking at the non-XDP receive_small path now and wondering how does
> >> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
> >
> > I don't understand the question. Look at add_recvbuf_small,
> > it adds a tiny buffer for head and then the skb.
> >
>
> Specifically this seems to fail with mergeable buffers disabled
>
> On the host:
>
> # ip link set dev tap0 mtu 9000
> # ping 22.2 -s 2048
>
> On the guest:
>
> # insmod ./drivers/net/virtio_net.ko
> # ip link set dev eth0 mtu 9000
Why would it work? You are sending a packet larger than ethernet MTU.
> With mergeable buffers enabled no problems it works as I expect at least.
We don't expect to get these packets but
mergeable is able to process them anyway.
It's an accident :)
>
> >
> >> I think
> >> this is what Jason is looking at as well? The mergeable case clearly looks at
> >> num_bufs in the descriptor to construct multi-buffer packets but nothing like
> >> that exists in the small_receive path as best I can tell.
> >>
> >> .John
> >
> > There's always a single buffer there.
> > BTW it was always a legacy path but if it's now important for people we
> > should probably check ANY_LAYOUT and put header linearly with the packet
> > if there.
> >
^ permalink raw reply
* Re: [for-next V3 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Doug Ledford @ 2017-01-10 4:53 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Leon Romanovsky, Eli Cohen, Matan Barak
In-Reply-To: <1483988453-28551-1-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
On Mon, 2017-01-09 at 21:00 +0200, Saeed Mahameed wrote:
> Hi Dave and Doug,
>
> Following the mlx5-odp submission, you can find here the 2nd mlx5
> submission for 4.11 as a pull-request including mlx5 4K UAR support
> from
> Eli Cohen (details below). For you Doug, this pull request will
> provide
> you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> net-next mlx5-odp merge commit.
>
> v1->v2:
> - Removed 64BIT arch dependency.
> v2->v3:
> - Removed extra space.
>
> Thank you,
> Saeed.
>
> The following changes since commit
> 525dfa2cdce4f5ab76251b5e57ebabf4f2dfc40c:
>
> Merge branch 'mlx5-odp' (2017-01-02 15:51:21 -0500)
This base commit looks harmless enough, but since it's likely just a
commit in your tree, it isn't really a clear indicator of how you set
this tree up....
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
> tags/mlx5-4kuar-for-4.11
>
> for you to fetch changes up to
> f502d834950a28e02651bb7e2cc7111ddd352644:
>
> net/mlx5: Activate support for 4K UARs (2017-01-09 20:25:10 +0200)
But once I pulled this, it became clear you guys based your tree on a
net-next starting point. You need to make that clear in the beginning.
And unless you can't avoid it, don't do it. I don't like having to
pull in Dave's net-next before I pull your code because it means I
can't submit my pull request to Linus during the merge window as a
single pull request, I have to split it up to be the stuff that is
based on net-next and the stuff based on my own next area.
>
> ----------------------------------------------------------------
> Eli Cohen (10):
> IB/mlx5: Fix kernel to user leak prevention logic
> IB/mlx5: Fix error handling order in create_kernel_qp
> mlx5: Fix naming convention with respect to UARs
> IB/mlx5: Fix retrieval of index to first hi class bfreg
> net/mlx5: Introduce blue flame register allocator
> net/mlx5: Add interface to get reference to a UAR
> IB/mlx5: Use blue flame register allocator in mlx5_ib
> IB/mlx5: Allow future extension of libmlx5 input data
> IB/mlx5: Support 4k UAR for libmlx5
> net/mlx5: Activate support for 4K UARs
>
> drivers/infiniband/hw/mlx5/cq.c | 10 +-
> drivers/infiniband/hw/mlx5/main.c | 278 ++++++++++-
> -----
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 32 +-
> drivers/infiniband/hw/mlx5/qp.c | 290 +++++++--
> --------
> drivers/net/ethernet/mellanox/mlx5/core/cq.c | 2 +
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 11 +-
> .../net/ethernet/mellanox/mlx5/core/en_common.c | 12 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +-
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 14 +-
> drivers/net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> drivers/net/ethernet/mellanox/mlx5/core/uar.c | 351
> +++++++++++++--------
> include/linux/mlx5/cq.h | 5 +-
> include/linux/mlx5/device.h | 23 +-
> include/linux/mlx5/doorbell.h | 6 +-
> include/linux/mlx5/driver.h | 81 ++---
> include/linux/mlx5/mlx5_ifc.h | 7 +-
> include/uapi/rdma/mlx5-abi.h | 19 +-
> 17 files changed, 672 insertions(+), 516 deletions(-)
Without going into excruciating detail, this is what I got when I
pulled your branch:
273 files changed, 8891 insertions(+), 6637 deletions(-)
create mode 100644 drivers/net/ethernet/qlogic/qede/qede_filter.c
create mode 100644 drivers/net/ethernet/qlogic/qede/qede_fp.c
Please don't do this unless you absolutely have to.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [for-next V2 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Doug Ledford @ 2017-01-10 4:29 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev, linux-rdma, Leon Romanovsky, Eli Cohen, Matan Barak
In-Reply-To: <1483890891-8767-1-git-send-email-saeedm@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Sun, 2017-01-08 at 17:54 +0200, Saeed Mahameed wrote:
> Hi Dave and Doug,
>
> Following the mlx5-odp submission, you can find here the 2nd mlx5
> submission for 4.11 as a pull-request including mlx5 4K UAR support
> from
> Eli Cohen (details below). For you Doug, this pull request will
> provide
> you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> net-next mlx5-odp merge commit.
>
> v1->v2:
> - Removed 64BIT arch dependency.
>
> Thank you,
> Saeed.
>
I know you have a couple issues to fix on respin (minor things as
pointed out). Otherwise, I've reviewed of the IB portion of the code
and have no objections.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-10 4:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110055023-mutt-send-email-mst@kernel.org>
On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
>> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
>>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>>>
>>>>
>>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>>>
>>>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>>>> MTU change in this case?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>> Why does host care?
>>>>>>>>>
>>>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>>>> I didn't know. What place in code does this?
>>>>>>>
>>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>>>> virtio doesn't have any code to drop packets on rx size.
>>>>>>
>>>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>>>> need to ensure packets fit in a page for the time being which is why I was
>>>>>> looking at this code and generated this patch.
>>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>>>
>>>>>
>>>>
>>>> Does this work for small buffers consider it always allocate skb with size
>>>> of GOOD_PACKET_LEN?
>>>
>>> Spec says hardware won't send in packets > max mtu in config space.
>>>
>>>> I think in any case, we should limit max_mtu to
>>>> GOOD_PACKET_LEN for small buffers.
>>>>
>>>> Thanks
>>>
>>> XDP seems to have a bunch of weird restrictions, I just
>>> do not like it that the logic spills out to all drivers.
>>> What if someone decides to extend it to two pages in the future?
>>> Recode it all in all drivers ...
>>>
>>> Why can't net core enforce mtu?
>>>
>>
>> OK I agree I'll put most the logic in rtnetlink.c when the program is added
>> or removed.
>>
>> But, I'm looking at the non-XDP receive_small path now and wondering how does
>> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
>
> I don't understand the question. Look at add_recvbuf_small,
> it adds a tiny buffer for head and then the skb.
>
Specifically this seems to fail with mergeable buffers disabled
On the host:
# ip link set dev tap0 mtu 9000
# ping 22.2 -s 2048
On the guest:
# insmod ./drivers/net/virtio_net.ko
# ip link set dev eth0 mtu 9000
With mergeable buffers enabled no problems it works as I expect at least.
>
>> I think
>> this is what Jason is looking at as well? The mergeable case clearly looks at
>> num_bufs in the descriptor to construct multi-buffer packets but nothing like
>> that exists in the small_receive path as best I can tell.
>>
>> .John
>
> There's always a single buffer there.
> BTW it was always a legacy path but if it's now important for people we
> should probably check ANY_LAYOUT and put header linearly with the packet
> if there.
>
^ permalink raw reply
* Re: [for-next V2 08/10] IB/mlx5: Allow future extension of libmlx5 input data
From: Doug Ledford @ 2017-01-10 4:24 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Leon Romanovsky, Eli Cohen, Matan Barak, Leon Romanovsky
In-Reply-To: <1483890891-8767-9-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Sun, 2017-01-08 at 17:54 +0200, Saeed Mahameed wrote:
> From: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Current check requests that new fields in struct
> mlx5_ib_alloc_ucontext_req_v2 that are not known to the driver be
> zero.
> This was introduced so new libraries passing additional information
> to
> the kernel through struct mlx5_ib_alloc_ucontext_req_v2 will be
> notified
> by old kernels that do not support their request by failing the
> operation. This schecme is problematic since it requires libmlx5 to
^ Typo
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-10 4:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, M. Braun,
Johannes Berg, David S . Miller, Felix Fietkau
In-Reply-To: <20170109133032.221f8669@xeon-e3>
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 3:55 UTC (permalink / raw)
To: John Fastabend
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <5874555A.3070307@gmail.com>
On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
> >>
> >>
> >> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> >>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> >>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> >>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> >>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> >>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> >>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
> >>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
> >>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
> >>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
> >>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
> >>>>>>>>>>>>> program load and does not block MTU changes after the program
> >>>>>>>>>>>>> has loaded.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> >>>>>>>>>>> needs to read the mtu via
> >>>>>>>>>>>
> >>>>>>>>>>> virtio_cread16(vdev, ...)
> >>>>>>>>>>>
> >>>>>>>>>>> or we may break the negotiated mtu.
> >>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> >>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
> >>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
> >>>>>>>>> after init time even without XDP which I assume should ideally result in a
> >>>>>>>>> notification if the MTU is negotiated.
> >>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
> >>>>>>>> MTU change in this case?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>> Why does host care?
> >>>>>>>
> >>>>>> Well the guest will drop packets after mtu has been reduced.
> >>>>> I didn't know. What place in code does this?
> >>>>>
> >>>> hmm in many of the drivers it is convention to use the mtu to set the rx
> >>>> buffer sizes and a receive side max length filter. For example in the Intel
> >>>> drivers if a packet with length greater than MTU + some headroom is received we
> >>>> drop it. I guess in the networking stack RX path though nothing forces this and
> >>>> virtio doesn't have any code to drop packets on rx size.
> >>>>
> >>>> In virtio I don't see any existing case currently. In the XDP case though we
> >>>> need to ensure packets fit in a page for the time being which is why I was
> >>>> looking at this code and generated this patch.
> >>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >>>
> >>>
> >>
> >> Does this work for small buffers consider it always allocate skb with size
> >> of GOOD_PACKET_LEN?
> >
> > Spec says hardware won't send in packets > max mtu in config space.
> >
> >> I think in any case, we should limit max_mtu to
> >> GOOD_PACKET_LEN for small buffers.
> >>
> >> Thanks
> >
> > XDP seems to have a bunch of weird restrictions, I just
> > do not like it that the logic spills out to all drivers.
> > What if someone decides to extend it to two pages in the future?
> > Recode it all in all drivers ...
> >
> > Why can't net core enforce mtu?
> >
>
> OK I agree I'll put most the logic in rtnetlink.c when the program is added
> or removed.
>
> But, I'm looking at the non-XDP receive_small path now and wondering how does
> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
I don't understand the question. Look at add_recvbuf_small,
it adds a tiny buffer for head and then the skb.
> I think
> this is what Jason is looking at as well? The mergeable case clearly looks at
> num_bufs in the descriptor to construct multi-buffer packets but nothing like
> that exists in the small_receive path as best I can tell.
>
> .John
There's always a single buffer there.
BTW it was always a legacy path but if it's now important for people we
should probably check ANY_LAYOUT and put header linearly with the packet
if there.
--
MST
^ permalink raw reply
* [PATCH] net: add the AF_QIPCRTR entries to family name tables
From: Suman Anna @ 2017-01-10 3:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Suman Anna, Courtney Cavin, Bjorn Andersson
Commit bdabad3e363d ("net: Add Qualcomm IPC router") introduced a
new address family. Update the family name tables accordingly so
that the lockdep initialization can use the proper names for this
family.
Cc: Courtney Cavin <courtney.cavin@sonymobile.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
net/core/sock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index f560e0826009..4eca27dc5c94 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -222,7 +222,7 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
"sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET" ,
"sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG" ,
"sk_lock-AF_NFC" , "sk_lock-AF_VSOCK" , "sk_lock-AF_KCM" ,
- "sk_lock-AF_MAX"
+ "sk_lock-AF_QIPCRTR", "sk_lock-AF_MAX"
};
static const char *const af_family_slock_key_strings[AF_MAX+1] = {
"slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
@@ -239,7 +239,7 @@ static const char *const af_family_slock_key_strings[AF_MAX+1] = {
"slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET" ,
"slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG" ,
"slock-AF_NFC" , "slock-AF_VSOCK" ,"slock-AF_KCM" ,
- "slock-AF_MAX"
+ "slock-AF_QIPCRTR", "slock-AF_MAX"
};
static const char *const af_family_clock_key_strings[AF_MAX+1] = {
"clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
@@ -256,7 +256,7 @@ static const char *const af_family_clock_key_strings[AF_MAX+1] = {
"clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET" ,
"clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG" ,
"clock-AF_NFC" , "clock-AF_VSOCK" , "clock-AF_KCM" ,
- "clock-AF_MAX"
+ "clock-AF_QIPCRTR", "clock-AF_MAX"
};
/*
--
2.10.2
^ permalink raw reply related
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Vishwanathapura, Niranjana @ 2017-01-10 3:39 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170109075104.GV15685-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Mon, Jan 09, 2017 at 09:51:04AM +0200, Leon Romanovsky wrote:
>On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
>> On 12/15/2016 9:52 AM, ira.weiny wrote:
>>
>> 2) With more than 60% of the code being MAD related, and another
>> significant chunk being hfi related, and only a minor bit (20% maybe?)
>> being net related,
>
>Hi Doug and Ira,
>
>I may admit that I didn't read the code very deep, but from brief
>overview, I didn't find support for the claim the "60% code is MAD related".
>It looks like the opposite thing will be more accurate.
>
>Can you help me to understand this claim? How did you come to this
>conclusion?
>
>Thanks
Hi Leon,
Here is the breakdown of patches based on functionality.
In this series, patches #3..#8 compose hfi_vnic driver. In that, patches #4, #7
and #8 are MAD focused (interfacing with MAD agent and handling MAD packets).
Patch #6 and half of #3 (_encap.c/h) are OPA encapsulation related. Patch #5 is
netdev statistic related (which includes statistics MAD definitions).
So, only part of patch #3 (_netdev.c and _ethtool.c) deals with interfacing
with netstack.
Those percentage numbers are based on actual lines of code in these patches
(files).
We are also looking into Jason’s suggestion to make hfi_vnic interface to the
bottom driver a generic interface. This will include moving some of the
netstack interfacing to the bottom hfi1 driver.
Niranjana
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Ahern @ 2017-01-10 3:39 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <CAKD1Yr0BnYNTYtCBHLy=KuhX3_23p8eQst61CoC0BHEr5PVkjQ@mail.gmail.com>
On 1/9/17 8:30 PM, Lorenzo Colitti wrote:
> On Tue, Jan 10, 2017 at 12:04 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
>>> I have no firsthand experience of this myself, but if the problems
>>> that Andrey reports above in this thread are real, then those would
>>> indicate that the code is not well-supported. Being unable to accept
>>> DAD is a pretty serious issue. Andrey, what version of the kernel did
>>> you see this on?
>>
>> Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
>
> No, this thread. I see message-ID 8cddkd-etc.ln1@banana.localnet in
> this thread. If you didn't get it, I also see it in the comments on
> patchwork - https://patchwork.ozlabs.org/patch/711956/
>
Odd that I did not get that -- checked spam and trash.
Andrey is missing 830218c1add1da16519b71909e5cf21522b7d062 which tells me the comment is not based on 4.10 or net-next:
$ git describe 830218c1add1da16519b71909e5cf21522b7d062
v4.8-14744-g830218c1add1
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-10 3:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20170110044910-mutt-send-email-mst@kernel.org>
On 2017年01月10日 10:51, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>
>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>> ---
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>
>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>
>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>> MTU change in this case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> Why does host care?
>>>>>>>
>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>> I didn't know. What place in code does this?
>>>>>
>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>> virtio doesn't have any code to drop packets on rx size.
>>>>
>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>> need to ensure packets fit in a page for the time being which is why I was
>>>> looking at this code and generated this patch.
>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>
>>>
>> Does this work for small buffers consider it always allocate skb with size
>> of GOOD_PACKET_LEN?
> Spec says hardware won't send in packets > max mtu in config space.
Yes, but if max mtu is greater than GOOD_PACKET_LEN, packet will be dropped.
>
>> I think in any case, we should limit max_mtu to
>> GOOD_PACKET_LEN for small buffers.
>>
>> Thanks
> XDP seems to have a bunch of weird restrictions, I just
> do not like it that the logic spills out to all drivers.
> What if someone decides to extend it to two pages in the future?
> Recode it all in all drivers ...
>
> Why can't net core enforce mtu?
>
Not sure it's a good idea to change mtu silently without notifying user.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-10 3:30 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <161222cb-5c61-d016-bc0f-2453fb0408b7@cumulusnetworks.com>
On Tue, Jan 10, 2017 at 12:04 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> > I have no firsthand experience of this myself, but if the problems
> > that Andrey reports above in this thread are real, then those would
> > indicate that the code is not well-supported. Being unable to accept
> > DAD is a pretty serious issue. Andrey, what version of the kernel did
> > you see this on?
>
> Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
No, this thread. I see message-ID 8cddkd-etc.ln1@banana.localnet in
this thread. If you didn't get it, I also see it in the comments on
patchwork - https://patchwork.ozlabs.org/patch/711956/
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-10 3:30 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110044910-mutt-send-email-mst@kernel.org>
On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>
>>
>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>> ---
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>
>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>
>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>> MTU change in this case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> Why does host care?
>>>>>>>
>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>> I didn't know. What place in code does this?
>>>>>
>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>> virtio doesn't have any code to drop packets on rx size.
>>>>
>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>> need to ensure packets fit in a page for the time being which is why I was
>>>> looking at this code and generated this patch.
>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>
>>>
>>
>> Does this work for small buffers consider it always allocate skb with size
>> of GOOD_PACKET_LEN?
>
> Spec says hardware won't send in packets > max mtu in config space.
>
>> I think in any case, we should limit max_mtu to
>> GOOD_PACKET_LEN for small buffers.
>>
>> Thanks
>
> XDP seems to have a bunch of weird restrictions, I just
> do not like it that the logic spills out to all drivers.
> What if someone decides to extend it to two pages in the future?
> Recode it all in all drivers ...
>
> Why can't net core enforce mtu?
>
OK I agree I'll put most the logic in rtnetlink.c when the program is added
or removed.
But, I'm looking at the non-XDP receive_small path now and wondering how does
multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?) I think
this is what Jason is looking at as well? The mergeable case clearly looks at
num_bufs in the descriptor to construct multi-buffer packets but nothing like
that exists in the small_receive path as best I can tell.
.John
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Ahern @ 2017-01-10 3:04 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <CAKD1Yr21W2Ce6mhAqfz+mFUPTn+xn3K_Lz2q5LA27f6V=9tTSQ@mail.gmail.com>
On 1/9/17 7:29 PM, Lorenzo Colitti wrote:
> On Tue, Jan 10, 2017 at 11:08 AM, David Ahern <dsa@cumulusnetworks.com> wrote:
>> That's news to me. What about IPv6 and VRF is not working or well-supported?
>
> I have no firsthand experience of this myself, but if the problems
> that Andrey reports above in this thread are real, then those would
> indicate that the code is not well-supported. Being unable to accept
> DAD is a pretty serious issue. Andrey, what version of the kernel did
> you see this on?
>
Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
Just a day or so ago I did a dup address test on an interface in a vrf and it worked fine, but perhaps I missed something.
^ permalink raw reply
* Re: [PATCH V4 net-next 1/3] vhost: better detection of available buffers
From: Michael S. Tsirkin @ 2017-01-10 2:57 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, kvm, stephen, wexu, stefanha
In-Reply-To: <5eb3b349-bbae-6438-d8ea-7df82a7babb4@redhat.com>
On Tue, Jan 10, 2017 at 10:22:42AM +0800, Jason Wang wrote:
>
>
> On 2017年01月10日 07:10, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 10:59:16AM +0800, Jason Wang wrote:
> > >
> > > On 2017年01月07日 03:55, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 06, 2017 at 10:13:15AM +0800, Jason Wang wrote:
> > > > > This patch tries to do several tweaks on vhost_vq_avail_empty() for a
> > > > > better performance:
> > > > >
> > > > > - check cached avail index first which could avoid userspace memory access.
> > > > > - using unlikely() for the failure of userspace access
> > > > > - check vq->last_avail_idx instead of cached avail index as the last
> > > > > step.
> > > > >
> > > > > This patch is need for batching supports which needs to peek whether
> > > > > or not there's still available buffers in the ring.
> > > > >
> > > > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > > > ---
> > > > > drivers/vhost/vhost.c | 8 ++++++--
> > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > index d643260..9f11838 100644
> > > > > --- a/drivers/vhost/vhost.c
> > > > > +++ b/drivers/vhost/vhost.c
> > > > > @@ -2241,11 +2241,15 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> > > > > __virtio16 avail_idx;
> > > > > int r;
> > > > > + if (vq->avail_idx != vq->last_avail_idx)
> > > > > + return false;
> > > > > +
> > > > > r = vhost_get_user(vq, avail_idx, &vq->avail->idx);
> > > > > - if (r)
> > > > > + if (unlikely(r))
> > > > > return false;
> > > > > + vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
> > > > > - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
> > > > > + return vq->avail_idx == vq->last_avail_idx;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
> > > > So again, this did not address the issue I pointed out in v1:
> > > > if we have 1 buffer in RX queue and
> > > > that is not enough to store the whole packet,
> > > > vhost_vq_avail_empty returns false, then we re-read
> > > > the descriptors again and again.
> > > >
> > > > You have saved a single index access but not the more expensive
> > > > descriptor access.
> > > Looks not, if I understand the code correctly, in this case, get_rx_bufs()
> > > will return zero, and we will try to enable rx kick and exit the loop.
> > >
> > > Thanks
> > I mean this:
> >
> > while (vhost_can_busy_poll(vq->dev, endtime) &&
> > vhost_vq_avail_empty(vq->dev, vq))
> > cpu_relax();
> > preempt_enable();
> > r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> > out_num, in_num, NULL, NULL);
> >
> >
> > vhost_vq_avail_empty returns false so we break out of the loop
> > and call vhost_get_vq_desc.
> >
> >
>
> But this is the code for polling tx vq not rx I think?
>
> Thanks
Oh, right.
I'll re-read this.
--
MST
^ permalink raw reply
* Re: [PATCH v2 13/13] net: ethernet: aquantia: Integrate AQtion 2.5/5 GB NIC driver
From: kbuild test robot @ 2017-01-10 2:52 UTC (permalink / raw)
To: Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, Simon Edelhaus,
Alexander Loktionov, Dmitrii Tarakanov, Pavel Belous
In-Reply-To: <66066b129bfac133b682dd4e4832004edf6615a0.1483999588.git.vomlehn@texas.net>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc3 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170110-084036
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__udivdi3" [drivers/net/ethernet/aquantia/atlantic.ko] undefined!
coccinelle warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/aquantia/aq_nic.c:584:3-4: Unneeded semicolon
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57957 bytes --]
^ permalink raw reply
* [PATCH] net: ethernet: aquantia: fix semicolon.cocci warnings
From: kbuild test robot @ 2017-01-10 2:52 UTC (permalink / raw)
To: Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, Simon Edelhaus,
Alexander Loktionov, Dmitrii Tarakanov, Pavel Belous
In-Reply-To: <66066b129bfac133b682dd4e4832004edf6615a0.1483999588.git.vomlehn@texas.net>
drivers/net/ethernet/aquantia/aq_nic.c:584:3-4: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: David VomLehn <vomlehn@texas.net>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
aq_nic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/aquantia/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/aq_nic.c
@@ -581,7 +581,7 @@ __acquires(&ring->lock)
aq_nic_ndev_queue_stop(self, ring->idx);
}
spin_unlock(&ring->lock);
- };
+ }
} while (--trys && !is_locked);
if (!is_locked)
^ permalink raw reply
* linux-next: manual merge of the y2038 tree with the net-next tree
From: Stephen Rothwell @ 2017-01-10 2:52 UTC (permalink / raw)
To: Arnd Bergmann, David Miller, Networking
Cc: linux-next, linux-kernel, David Howells, Tina Ruchandani
Hi Arnd,
Today's linux-next merge of the y2038 tree got a conflict in:
fs/afs/main.c
between commit:
8e8d7f13b6d5 ("afs: Add some tracepoints")
from the net-next tree and commit:
549eb7b22e24 ("AFS: Correctly use 64-bit time for UUID")
from the y2038 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/afs/main.c
index f8188feb03ad,129ff432391c..000000000000
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@@ -14,8 -14,7 +14,9 @@@
#include <linux/init.h>
#include <linux/completion.h>
#include <linux/sched.h>
+#include <linux/random.h>
+#define CREATE_TRACE_POINTS
+ #include <linux/ktime.h>
#include "internal.h"
MODULE_DESCRIPTION("AFS Client File System");
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 2:51 UTC (permalink / raw)
To: Jason Wang
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <9102bb4b-223a-d441-7546-8b4144d970fb@redhat.com>
On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>
>
> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> > > On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> > > > > On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> > > > > > On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> > > > > > > On 2017年01月05日 02:57, John Fastabend wrote:
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > On 2017年01月04日 00:48, John Fastabend wrote:
> > > > > > > > > > On 17-01-02 10:14 PM, Jason Wang wrote:
> > > > > > > > > > > On 2017年01月03日 06:30, John Fastabend wrote:
> > > > > > > > > > > > XDP programs can not consume multiple pages so we cap the MTU to
> > > > > > > > > > > > avoid this case. Virtio-net however only checks the MTU at XDP
> > > > > > > > > > > > program load and does not block MTU changes after the program
> > > > > > > > > > > > has loaded.
> > > > > > > > > > > >
> > > > > > > > > > > > This patch sets/clears the max_mtu value at XDP load/unload time.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> > > > > > > > > > > > ---
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > > OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> > > > > > > > > > needs to read the mtu via
> > > > > > > > > >
> > > > > > > > > > virtio_cread16(vdev, ...)
> > > > > > > > > >
> > > > > > > > > > or we may break the negotiated mtu.
> > > > > > > > > Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> > > > > > > > > the device about the mtu in this case which is not supported by virtio now.
> > > > > > > > Note this is not really a XDP specific problem. The guest can change the MTU
> > > > > > > > after init time even without XDP which I assume should ideally result in a
> > > > > > > > notification if the MTU is negotiated.
> > > > > > > Yes, Michael, do you think we need add some mechanism to notify host about
> > > > > > > MTU change in this case?
> > > > > > >
> > > > > > > Thanks
> > > > > > Why does host care?
> > > > > >
> > > > > Well the guest will drop packets after mtu has been reduced.
> > > > I didn't know. What place in code does this?
> > > >
> > > hmm in many of the drivers it is convention to use the mtu to set the rx
> > > buffer sizes and a receive side max length filter. For example in the Intel
> > > drivers if a packet with length greater than MTU + some headroom is received we
> > > drop it. I guess in the networking stack RX path though nothing forces this and
> > > virtio doesn't have any code to drop packets on rx size.
> > >
> > > In virtio I don't see any existing case currently. In the XDP case though we
> > > need to ensure packets fit in a page for the time being which is why I was
> > > looking at this code and generated this patch.
> > I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >
> >
>
> Does this work for small buffers consider it always allocate skb with size
> of GOOD_PACKET_LEN?
Spec says hardware won't send in packets > max mtu in config space.
> I think in any case, we should limit max_mtu to
> GOOD_PACKET_LEN for small buffers.
>
> Thanks
XDP seems to have a bunch of weird restrictions, I just
do not like it that the logic spills out to all drivers.
What if someone decides to extend it to two pages in the future?
Recode it all in all drivers ...
Why can't net core enforce mtu?
--
MST
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox