Re: changes to make ethernet packets able to be unaligned...

From: Mike Silbersack (silby_at_silby.com)
Date: 03/18/05

  • Next message: John-Mark Gurney: "Re: changes to make ethernet packets able to be unaligned..." 
    Date: Fri, 18 Mar 2005 02:48:26 -0600 (CST)
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>

    On Fri, 18 Mar 2005, John-Mark Gurney wrote:

    >> I'm confused - don't sparc64 and alpha have similar alignment
    >> requirements? Why does arm require code changes?
    >
    > yes, the alignment constraints for arm are the same.. the reason I
    > said the above is only for arm is the epe driver (which is only on
    > an ARM core) has been made to use the new feature...
    >
    > The changes to ip_input.c will work with other drivers as well... it
    > just needs to make sure that the proper defines are in amd64 and i386
    > so that we don't do the fix up when we don't need to...
    >
    > --
    > John-Mark Gurney Voice: +1 415 225 5579

    Ok, I see what you're saying now, I had forgotten the #ifdef i386 sections
    we have scattered throughout the network drivers. When I read your
    original commit, I was thinking about the transmit paths in drivers, which
    is why m_copyup made no sense to me.

    Moving the alignment out of the drivers and into a common place seems like
    a good idea, but I wonder if it should be done in the ethernet code
    instead of in the ip code; won't other protocols have unaligned access
    problems if the change is made exactly as is?

    Mike "Silby" Silbersack
    _______________________________________________
    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: John-Mark Gurney: "Re: changes to make ethernet packets able to be unaligned..."

    Relevant Pages

    • Re: To embed or not to embed?
      ... It is amazing how many commercial cards only support Windows with these ... system can happen a lot quicker than updates to drivers. ... With the cost of some ARMs you may well consider having an ARM on each ...
      (comp.arch.embedded)
    • Re: [patch 2.6.18-rc1] genirq: {en,dis}able_irq_wake() need refcounting too
      ... migrating most ARM users over to the new APIs, ... To recap, the driver code _is_ that symmetric, it's just the implementation ... I'll forward this patch to the the ARM kernel list, ... There aren't many in-tree drivers using these calls. ...
      (Linux-Kernel)
    • Re: ARM development board
      ... They have other ARM variants as well. ... Linux kernal on our ARM9 with good results, and built apps on top of it. ... > the platforms I have come across do not include SPI or IIC drivers. ...
      (comp.arch.embedded)
    • Re: 32 bit architecture advice (ARM, PPC etc.)
      ... I'd have to say that ARM is considerably easier to understand. ... drivers that can't be compiled - USB peripherals, ... a bunch of definitions were deleted or renamed in the USB handling code, ... The complementary question is how long it will be before your hardware is ...
      (comp.os.linux.embedded)
    • Re: changes to make ethernet packets able to be unaligned...
      ... On Thu, 17 Mar 2005, John-Mark Gurney wrote: ... > This currently is only for arm and I plan to now remove the code from ... Why does arm require code changes? ... Mike "Silby" Silbersack ...
      (freebsd-net)
    Loading