From owner-freebsd-scsi@freebsd.org Mon Jun 26 13:02:10 2017 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D257D86471; Mon, 26 Jun 2017 13:02:10 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1D40783BF; Mon, 26 Jun 2017 13:02:09 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-vk0-x230.google.com with SMTP id 191so319311vko.2; Mon, 26 Jun 2017 06:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jmEyFFLQSYeM6xEEdWTEN7u+GglUoER+WvbyAu6RKCY=; b=dDvce0nc7uS/JU9udWXQ7W9S76X6QrhtZrZSAqpnEA7RKlo6lnuXNGoG6glYfGd3k4 hdiR47Kf51r3abXe/SuQG8fbklEhugvrVXnOHJ8XDciWqMPWcbK1zi3sx2guZE2nEfKC KEvalK6kwd4gUXBZfF3+ZOrg2MoNElgjRSJ18tloglEfLzABw/80GOdf8Y/MBxmzZYA4 h59lzEeGIff/4QVR469hjAHBknuiGhuA3SCuFWrs6Mm7rS9YoHiaaWvw+d4Y7vrPSCra m8EcDdrv7oCLXD4aQ44pu2nKKH1jvyh44u7fc7F1L5ubTi1GJA5WrGgwTG9xub+q+uUh mJYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jmEyFFLQSYeM6xEEdWTEN7u+GglUoER+WvbyAu6RKCY=; b=OpwFFiLa99YfU11FpYER1ZPCHXrUwSgylXiPb5PJjyoNG+gz0F20DXXOm39/ub1ZWs Rc4B0p0dVCuDg3/LI0Vu9symqeGF7a7v2EssyvrgarMfxn3i37TgbLiQsEOc2WtKiwgj 8bsnDJczeryG4loGPARdKhHv/UsFdisesMMcZ/BuDc/QpDV6aL4KkEPwujNVR34zv+73 +NIaD68RUw9hjUH7910MfHGtx8W3MokbKv2zrXfQ5hLmDRDJ5aQe/q1awrRqoDS9+m40 JlpKYrt2wD17+iqrtSYEY+XZsHLk/6AwJqIeKR9tvedC250PzHW62PGWEEBHqmwEFNss xrHg== X-Gm-Message-State: AKS2vOy7gT2SeyTpV0hNhYxqr1fae0A7+t3kVElb6vrNhWhmTz9C9GV2 owh5XTKwovq87NRMnTQsoAZP9Zcezg== X-Received: by 10.31.222.193 with SMTP id v184mr32122vkg.73.1498482129070; Mon, 26 Jun 2017 06:02:09 -0700 (PDT) MIME-Version: 1.0 Sender: etnapierala@gmail.com Received: by 10.176.83.198 with HTTP; Mon, 26 Jun 2017 06:02:08 -0700 (PDT) In-Reply-To: References: <486A6DA0-54C8-40DF-8437-F6E382DA01A8@gmail.com> <6a31ef00-5f7a-d36e-d5e6-0414e8b813c7@selasky.org> <613AFD8E-72B2-4E3F-9C70-1D1E43109B8A@gmail.com> <2c9a9c2652a74d8eb4b34f5a32c7ad5c@AM5PR0502MB2916.eurprd05.prod.outlook.com> <52A2608C-A57E-4E75-A952-F4776BA23CA4@gmail.com> <9B507AA6-40FE-4B8D-853F-2A9422A2DF67@gmail.com> From: Edward Napierala Date: Mon, 26 Jun 2017 14:02:08 +0100 X-Google-Sender-Auth: oGGxrb1a2EIfNU6zTD5eQv8QPbk Message-ID: Subject: Re: mbuf_jumbo_9k & iSCSI failing To: Ryan Stone Cc: Ben RUBSON , FreeBSD Net , "freebsd-scsi@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 13:02:10 -0000 2017-06-25 16:32 GMT+01:00 Ryan Stone : > Having looking at the original email more closely, I see that you showed an > mlxen interface with a 9020 MTU. Seeing allocation failures of 9k mbuf > clusters increase while you are far below the zone's limit means that > you're definitely running into the bug I'm describing, and this bug could > plausibly cause the iSCSI errors that you describe. > > The issue is that the newer version of the driver tries to allocate a > single buffer to accommodate an MTU-sized packet. Over time, however, > memory will become fragmented and eventually it can become impossible to > allocate a 9k physically contiguous buffer. When this happens the driver > is unable to allocate buffers to receive packets and is forced to drop > them. Presumably, if iSCSI suffers too many packet drops it will terminate > the connection. [..] More specifically, it will terminate the connection when there's no "ping reply" from the other side for the configured amount of time, which defaults to five seconds. It can be changed using the kern.iscsi.ping_timeout sysctl, as described in iscsi(4).