Age | Commit message (Collapse) | Author | Files | Lines |
|
In L3 submodes, there were two memory leaks
- when a L3 core was restarted, causing around 2MB leak and a
potential issue after 256 start/stop
- a potential mbuf leak when handling arp replies
Those have been fixed
Change-Id: I348478fa5967936297850432e93667e12b0adac4
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When no arp reply was received in l3 mode, the requesting core
continuously sends ARP requests every seconds (which is correct).
But master core was keeping a list of all requests, while all
those requests are the same, resulting in potential table overflow.
Change-Id: I13aa1ec4ea88404a690a25678fb6ec72df19a9b9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Print IP address in a.b.c.d format instead of one 32-bit number.
Better align debugging information in log file
Change-Id: Icfab30836ba83d53f700fcfbdfbd7cf238ed7bf8
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: I5611ead4b61b23d6c1c983852e8c75619e08ecf9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When multiple tasks generate to the same ip in l3 mode (i.e. with arp
support), all those tasks generate arp requests. we need to make sure
that they all receive a arp-reply i.e. that the master broadcast
the reply to all those cores.
Change-Id: I7e89196497a1016a94dde167f212b1f6ed03bcfe
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|