From owner-freebsd-xen@FreeBSD.ORG Fri Sep 5 19:05:35 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 515D796D for ; Fri, 5 Sep 2014 19:05:35 +0000 (UTC) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1776D1F55 for ; Fri, 5 Sep 2014 19:05:34 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id a141so8027715oig.35 for ; Fri, 05 Sep 2014 12:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=averesystems.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=hw+g9+TnF6G4CaAjucoSSzCCcsJNrrG08SYuE+jzeBE=; b=FxjgHeYYs2Z5PfzXvUrKZM3rWkYPhkVFN85ZN2Ha9vJuetcykxaoovrN94BGRoL9sH 8DRasIYEhA//Tgt68610bclAiHDkhQj+B0iA6OiaFHVsTluCJf+z5dJITyiKZ44pIZmv KnoCl9+SSMVeR/b62aCcmp0fdRQxhE0oeb4GA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hw+g9+TnF6G4CaAjucoSSzCCcsJNrrG08SYuE+jzeBE=; b=iVqF4v1qjwfDQ8mEgykhsYaiw5onhWGDPdU4FZEV3up4xoxlC6Jxf673e56uv1ib7g TFBNL5BofTfJy4gMwgvfrTtyAOs01pNxZ5oGyDdsrdPY5ZearaK4Nju5vITa7yUrkU91 M8ZLEshvseZvoMCs/sHkAs3ZyvyyLsUSzYmNrqLW/a59I7uF6UXHxFoxiW73XdL/1RyF XMGWPPOWNJUek0gY7+w6+ckpBc5alQoqcnx8JSDqvaQMDYDj7lbDGtLxHy5pU4WiMcnM bRbEOeXL+jK8bC02T9xPrysKmlmYiDQyetKI/hIsaqRJdCqo6pIGAIieThQjAX71OjHh MEYQ== X-Gm-Message-State: ALoCoQkFOJicJxieorUlTX22l45q5tI5k5VvafVt95VYrajeYKMAejYtHgbCPof/ohJf/0bgPlPv MIME-Version: 1.0 X-Received: by 10.182.60.98 with SMTP id g2mr16195525obr.6.1409943934291; Fri, 05 Sep 2014 12:05:34 -0700 (PDT) Received: by 10.76.12.70 with HTTP; Fri, 5 Sep 2014 12:05:34 -0700 (PDT) Date: Fri, 5 Sep 2014 15:05:34 -0400 Message-ID: Subject: netfront driver with mbufs > 4K From: Jeremiah Lott To: freebsd-xen@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:05:35 -0000 It seems the netback driver (at least in linux) cannot handle a fragment passed to it that crosses a 4K boundary. Here is the code from the linux netback driver that enforces this: if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) { netdev_err(vif->dev, "Cross page boundary, txp->offset: %x, size: %u\n", txp->offset, txp->size); xenvif_fatal_tx_err(vif); return -EINVAL; } The netfront driver in FreeBSD creates a fragment for each mbuf in the chain, but does not check if the mbuf crosses a 4K boundary. For mbufs allocated from the zone_jumbo9 or zone_jumbo16 uma zones, it can create fragments that are too large and/or cross a page boundary. In this case the netback stops responding, and the network interface appears to "hang". It is also a problem for mbufs that have external data attached to them (as the data could be any size or alignment). It seems that the netfront driver needs split mbufs that span page boundaries into multiple fragments. I'm starting to think about code to do that, but I figured I'd put this out there if anyone has suggestions on handling this. Thanks, Jeremiah Lott Avere Systems