Re: if_tap unaligned access problem

From: Sten Spans (sten_at_blinkenlights.nl)
Date: 05/03/05

  • Next message: Mike Silbersack: "Re: if_tap unaligned access problem"
    Date: Tue, 3 May 2005 01:35:39 +0200 (CEST)
    To: Mike Silbersack <silby@silby.com>
    
    

    On Mon, 2 May 2005, Mike Silbersack wrote:

    >
    > On Thu, 28 Apr 2005, Bruce M Simpson wrote:
    >
    >> jmg's suggestion of bringing in the NetBSD patches to allow the entire
    >> network stack to be compiled with unaligned accesses (for those platforms
    >> which support it) is interesting because it can simplify or eliminate
    >> some of the acrobatics needed in network drivers to deal with the mbuf
    >> alignment.
    >
    > I'm too lazy to benchmark, but I suspect that having the ethernet code shift
    > the packet backwards by two bytes after it strips off the ethernet header is
    > going to be faster than requiring ip_input to allocate a new mbuf for each
    > received packet.
    >
    > Such a change would also ensure that we don't break all the other protocols
    > that jmg didn't touch in his patch.

    For the if_tap case fixing the driver ( or rather changing m_uiotombuf )
    is definately the correct solution. No sensible person would say otherwise.
    Once the if_tap change is properly tested and signed off it should
    make it into the tree.

    But on the proposed alignment changes:

    If you would look at the netbsd url (
    http://mail-index.netbsd.org/source-changes/2002/07/01/0001.html )

    You would see that:

    1- This code only triggers for strict alignment architectures
        No inpact for i386 and amd64.

    2- This code only triggers when the protocol header is unaligned.
        If the l2 driver is ok then this code won't be triggered.

    3- Only the link headers are aligned, not the entire mbuf(chain).
        This should limit the performance impact quite a bit.
        It might even alow us to eliminate quite a bit of ugly
        mbuf juggling in certain drivers.
        http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_input.c.diff?r1=1.153&r2=1.154&f=h
        ( Or the comments are incorrect, and I need to do more code reading :)

    To summarize:

    These changes will stop kernel crashes on alpha and sparc for drivers
    which are currently broken. All the drivers which currently work
    will not trigger this code.

    I haven't looked at every drivers but this change looks quite
    a bit cleaner than most of the tricks pulled in ethernet drivers,
    especially when jumboframes are involved.

    Netbsd has had 3 years to test this code, it can't be all bad :)

    -- 
    Sten Spans
    "There is a crack in everything, that's how the light gets in."
    Leonard Cohen - Anthem
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Mike Silbersack: "Re: if_tap unaligned access problem"

    Relevant Pages

    • Re: ether_crc32_[bl]e()
      ... >These CRCs are used all over our network drivers, ... These could be factored out of some thirty drivers. ... >NetBSD has done so, btw. ... lines in more than a handful of drivers you can assume that we want it. ...
      (freebsd-arch)
    • Re: [PATCH] synchronize_irq needs a barrier
      ... most network drivars has a packet queue and in case of dmfe it is located in main memory, ... you before your suspend routine is called.... ... Other network drivers has a bit more complicated .suspend/.resume routines, ... I think the network stack does that nowadays but we'll have to double ...
      (Linux-Kernel)
    • Re: [PATCH] synchronize_irq needs a barrier
      ... most network drivars has a packet queue and in case of dmfe it is located in main memory, ... you before your suspend routine is called.... ... it too on my drivers. ... I think the network stack does that nowadays but we'll have to double ...
      (Linux-Kernel)
    • [PATCH] Export touch_nmi_watchdog
      ... Sometimes drivers do long things with interrupt off and the NMI watchdog ... triggers quickly. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Export touch_nmi_watchdog
      ... >> Sometimes drivers do long things with interrupt off and the NMI watchdog ... This mostly happens in error handling. ... triggers the watchdog when it gets into any error handling situation) ...
      (Linux-Kernel)