element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
Software Application Development LwIP: Pre-Fragmenting Large UDP Raw Packets
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 0 replies
  • Subscribers 310 subscribers
  • Views 138 views
  • Users 0 members are here
Related

LwIP: Pre-Fragmenting Large UDP Raw Packets

twv
twv over 8 years ago

I've got an LwIP raw UDP-based application running on a MicroZed. Generally works fine, thousands of packets in either direction. I now want to increase the size of the packets I'm transmitting such that they could span multiple MAC frames. At around 5KB packets, LwIP is cheerfully fragmenting away, and the system seems to operate as before (just with greater bandwidth). But at 7KB packets, the system runs for only varying short times before it crashes. I've heard of others in my circles avoiding outbound LwIP UDP raw fragmentation completely because of similar symptoms observed on Zynq.

 

I'd like to try a work-around that's not quite as extreme as sending frame-sized packets. I think I should be able to allocate multiple frame-sized pbufs and chain them into a single packet pbuf, all pointing their payloads to different parts of my source memory buffer. The intent is to serve upd_sendto() with pre-digested fragment pbufs. If this allows me to enter LwIP further down the call stack (but still within the API), so much the better. I've been looking for examples of how to do this efficiently, but haven't turned up anything. Questions:

 

a) should I allocate as PBUF_ROM or PBUF_REF to minimize LwIP copying -- preferably, I'd like LwIP to not have to copy anything but link and IP headers until it hands the contained pbufs to the GEM DMA (my memory buffer, not really ROM but it will be stable for greater than 500us, is itself in non-cacheable space).

 

b) should I allocate the head pbuf as PBUF_TRANSPORT and the rest as PBUF_IP so there's enough room for frame headers? Or are the headers in the payload, so should I allocate a separate pbuf for just TRANSPORT headers and the rest as PBUF_RAW?

 

c) once allocated, do I just pbuf_cat() them together so I don't have to worry about refs? For best efficiency, do I cat from the head (2nd onto 1st), or from the tail (last onto penultimate)?

 

d) then after a good timeout after sending, do I just pbuf_free() the head pbuf (the way I free received fragmented packets)?

 

If anyone has experience with this, I'd appreciate any tips or examples. Thanks

 

twv@

  • Sign in to reply
  • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube