Re: ports/net/e169-stats (was: UMTS Huawei monitor)
El día Tuesday, January 31, 2012 a las 01:43:47PM +0100, Matthias Apitz
escribió:
> At the end I decided to understand the source code. Btw: the device port
> /dev/cuaU0.n is hardcoded set to .2, while mine is .3 for the E1750;
Hello,
While digging into the source, I saw that I was wrong saying that; only
the default is hardcoded set to .2 and if one provides an argument on
the cmd line, this is used; don't know how I have overlooked that;
Edwin, please accept my honestly sorry for this;
I did some minor cosmetic changes (attached) for your consideration;
in any case, now I have it clear why in some place where I sit reading
with my netbook, the bandwidth and speed is so poor: the RSSI value
there is only 2-3 in that place; it is a relatively new building with a
lot of steel and concrete; the distance from the table to the windows is
around 5-6 meters; when I move to the window the RSSI value is ~14,
outside as well; in short words: your tool, Edwin, helped me a lot to
get a clear picture of my problem; thanks!
matthias
--
Matthias Apitz
e - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
*** e169-stats.c.orig 2011-03-08 07:47:40.0 +0100
--- e169-stats.c2012-01-31 22:14:32.0 +0100
***
*** 120,126
v3 /= 1000;
}
! mvwprintw(screen, Y - 1 - (v2 * yscale) / v1, 0, "%u%cB", v3, prefix);
return (v1);
}
--- 120,128
v3 /= 1000;
}
! wattrset(screen, colour[scbar[0].sb_mode]);
! mvwprintw(screen, Y - 1 - (v2 * yscale) / v1, 0, "%u%cbps", v3*8,
prefix);
! wattrset(screen, colour[1]);
return (v1);
}
***
*** 153,160
bytestosomething(rxtotal, srxtotal, sizeof(srxtotal));
bytestosomething(txtotal, stxtotal, sizeof(stxtotal));
! bytestosomething(rxnow, srxnow, sizeof(srxnow));
! bytestosomething(txnow, stxnow, sizeof(stxnow));
int X = getmaxx(screen);
int Y = getmaxy(screen);
--- 155,164
bytestosomething(rxtotal, srxtotal, sizeof(srxtotal));
bytestosomething(txtotal, stxtotal, sizeof(stxtotal));
! // bytestosomething(rxnow, srxnow, sizeof(srxnow));
! // bytestosomething(txnow, stxnow, sizeof(stxnow));
! snprintf(srxnow, sizeof(srxnow), "%1.03f Mbps",
(double)rxnow*8/1024/1024);
! snprintf(stxnow, sizeof(stxnow), "%1.03f Mbps",
(double)txnow*8/1024/1024);
int X = getmaxx(screen);
int Y = getmaxy(screen);
***
*** 176,183
mvwprintw(screen, 3, 0, "RSSI: %d dBm (%d)",
2 * scbar[0].sb_ssi - 113, scbar[0].sb_ssi);
mvwprintw(screen, 4, 0, "Total: %s / %s", stxtotal, srxtotal);
mvwprintw(screen, 5, 0, "Now: %s / %s", stxnow, srxnow);
! //mvwprintw(screen, 6, 0, "Last: %d / %d", scbar[0].sb_tx,
scbar[0].sb_rx);
int i;
for (i = -9; i <= 0; i++) {
--- 180,189
mvwprintw(screen, 3, 0, "RSSI: %d dBm (%d)",
2 * scbar[0].sb_ssi - 113, scbar[0].sb_ssi);
mvwprintw(screen, 4, 0, "Total: %s / %s", stxtotal, srxtotal);
+ wattrset(screen, colour[scbar[0].sb_mode]);
mvwprintw(screen, 5, 0, "Now: %s / %s", stxnow, srxnow);
! wattrset(screen, colour[1]);
! //mvwprintw(screen, 6, 0, "Last: %d / %d", scbar[1].sb_tx,
scbar[1].sb_rx);
int i;
for (i = -9; i <= 0; i++) {
***
*** 216,230
mvwaddch(screen, Y - 1 - (ssi / LENGTH(c)), X - i,
colour[scbar[i].sb_mode] | c[ssi % LENGTH(c)]);
}
if (scbar[i].sb_tx > 0) {
mvwaddch(screen,
Y - 1 - (scbar[i].sb_tx * yscale) / vol,
X - i, colour[scbar[i].sb_mode] | '^');
}
if (scbar[i].sb_rx > 0) {
mvwaddch(screen,
Y - 1 - (scbar[i].sb_rx * yscale) / vol,
!X - i, colour[scbar[i].sb_mode] | 'v');
}
if (scbar[i].sb_rx == 0 && scbar[i].sb_tx == 0) {
mvwaddch(screen, Y - 1,
--- 222,244
mvwaddch(screen, Y - 1 - (ssi / LENGTH(c)), X - i,
colour[scbar[i].sb_mode] | c[ssi % LENGTH(c)]);
}
+ int y1, y2;
+ int v;
if (scbar[i].sb_tx > 0) {
+ y1 = Y - 1 - (scbar[i].sb_tx * yscale) / vol;
mvwaddch(screen,
Y - 1 - (scbar[i].sb_tx * yscale) / vol,
X - i, colour[scbar[i].sb_mode] | '^');
}
if (scbar
Re[2]: netisr defered - active only one thread
Здравствуйте, Andrey. Вы писали 2 февраля 2012 г., 8:35:23: AZ> On 02.02.2012 5:11, Alexander V. Chernikov wrote: >> On 01.02.2012 20:45, Andrey Zonov wrote: >>> Hi, >>> >>> I'm trying to tune machine with 8.2-STABLE for heavy network load and >>> now playing with netisr. Could anyone explain me why actually works only >>> one netisr thread if I set them to 8? >> >> Can you please supply `nestat -Q` output and clarify you usage pattern ? >> (I mean, this is router/web server/some kind of traffic receiver/etc..). >> For example, flow policy does not balance traffic from single flow >> between different CPUs. >> AZ> This is a web server with multiple nginx instances. 5k/sec accepted AZ> connections. Input packet rate is 35kpps, output - 25kpps. AZ> I thought of changing policy for IP, but how can I do this (without AZ> patching)? Is it safe? AZ> netstat -Q (I turned on direct & direct force for now): AZ> Configuration: AZ> Setting Value Maximum AZ> Thread count 88 AZ> Default queue limit25610240 AZ> Direct dispatchenabled n/a AZ> Forced direct dispatch enabled n/a AZ> Threads bound to CPUs enabled n/a AZ> Protocols: AZ> Name Proto QLimit Policy Flags AZ> ip 1 5000 flow --- AZ> igmp 2256 source --- AZ> rtsock 3256 source --- AZ> arp7256 source --- AZ> ip6 10256 flow --- AZ> Workstreams: AZ> WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled AZ> 0 0 ip 0 0 1125716000 1125716 AZ>igmp 0 00000 AZ>rtsock 0 1000 102 102 AZ>arp0 0 27000 27 AZ>ip60 00000 AZ> 1 1 ip 0 0 1222701000 1222701 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 46000 46 AZ>ip60 00000 AZ> 2 2 ip 0 0 1184381000 1184381 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 45000 45 AZ>ip60 00000 AZ> 3 3 ip 0 0 1191094000 1191094 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 54000 54 AZ>ip60 00000 AZ> 4 4 ip 0 0 846165000 846165 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 19000 19 AZ>ip60 00000 AZ> 5 5 ip 0 0 849478000 849478 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 27000 27 AZ>ip60 00000 AZ> 6 6 ip 0 0 870836000 870836 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 0 29000 29 AZ>ip60 00000 AZ> 7 7 ip 0 5000 5943205 910862 3453459 4047784 AZ>igmp 0 00000 AZ>rtsock 0 00000 AZ>arp0 5 2100 109 130 AZ>ip60 10001 same problem, it is because one netisr take 100% so other threads stops?? to work fine. or packet scheduler has disbalanced scheduler and still trying to schedule packet to netisr:7 despite on it is 100% busy. -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.or
Re: [PATCH] multiple instances of ipfw(4)
On Tue, Jan 31, 2012 at 12:02 PM, Luigi Rizzo wrote: > On Mon, Jan 30, 2012 at 01:01:13PM +0100, Ermal Lu?i wrote: >> Hello, >> >> from needs on pfSense a patch for allowing multiple intances of >> ipfw(4) in kernel to co-exist was developed. >> It can be found here >> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff >> >> It is used in conjuction with this tool >> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c >> It allows creation of contextes/instances and assignment of specific >> interfaces to specific contexts/instances. >> >> Surely i know that this is not the best way to implement generically >> but it gets the job done for us as it is, read below. >> >> What i would like to know is if there is interest to see such >> functionality in FreeBSD? >> >> I am asking first to see if there is some consensus about this as a >> feature, needed or not! >> If interest is shown i will transform the patch to allow: >> - ipfw(8) to manage the contextes create/destroy >> - ipfw(8) to manage interface membership. Closing the race of two >> parallell clients modifying different contextes. >> >> There is another design choice to be made about storing the membership >> of interfaces into contexts/instances, but i do not see that as >> blocking. >> >> It is quite handy feature, which can be exploited even to scale on SMP >> machines by extending it to bind a specific instance(with its >> interaces) to a specific CPU/core?! >> >> Comments/Feedback expected, > > if i understand what the patch does, i think it makes sense to be > able to hook ipfw instances to specific interfaces/sets of interfaces, > as it permits the writing of more readable rulesets. Right now the > workaround is start the ruleset with skipto rules matching on > interface names, and then use some discipline in "reserving" a range > of rule numbers to each interface. > > Before making more changes to the code, > it would help if you could give a high level description of > > 1. what the change does and how specific cases are handled. E.g. > With this change you can create multiple rulesets (contexts ?) > and bind one or more interfaces to a context. In man simple words it can give you multiple rulesets in ipfw(4) together with ability to restrict the ruleset to specific interfaces. As it is written today it forces you to create the relation of interface(s) and rulesets explicitly. Though its debatable you would want the freedom of one interface to more than one ruleset. The target of this patch was strictly layer2 filtering with ipfw(4) and allowing easy managebility of multiple instances of an userland application using ipfw(4) at layer2 for filtering/forwarding/QoS purposes. > - what happens with outgoing packets where the context > to be picked up depend on the route in effect at the time > of the transmission ? For this i have not given much thought but makes sense only on satetful tracking of sessions in ipfw(4). See below for a solution implemented along with this patch. > - what happens with encapsulated interfaces (vlan) ? Well by the very nature of this patch is that you have to explicitly assign an interface to the ruleset. This by definition of vlan/cloned interfaces in FreeBSD means you have to assign them to the ruleset explicitly too. In pfSense for example, since ipfw(4) is used exlusivly at layer2 it was necessary to introduce another flag and be very explicit on which interface is considered for filtering in ipfw(4). Also problems were faced on determining what was considered incoming and what outgoing when calling the ipfw hooks. This was changed to be explicit as well. Otherwise you have to play a tricky game of rules and what interface a particual pattern of traffic belongs and write respective rules about it, which is no fun at all from implementations and administration point of view. > - can you skipto across contexts (i guess not) ? > No its not there but it can be a possible addition. > 2. how intrusive are code changes ? The kernel patch you show > seems small, which makes sense as i believe all is needed is > to start from a specific chain instead of the default one when > an interface is bound to a context. A few comments: > - if you use one of the if_ispare directly, instead of > renaming it to if_context, this would make backporting and > testing easier. > - I think the explosion of sockopt names is a bad thing. > The IP_FW3 command was introduced exactly to have a single > entry point to the firewall and avoid a ton of new names > in raw_ip.c and in.h > - can you reduce the number of global ipfw-related variables ? > There used to be one (layer3_chain), now you have 3 of them. > You should delete layer3_chain and replace it with another > single global (could b
HowTo easy use IPFW
this is the mine script which helps me keep my firewall very clean and safe. It is easy to understand even if you have a thousands rules, I think =) please comment. PS. If anybody may, please put into ports tree. thank you. usr-local-etc-firewall.rar Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
8139 driver question
Hello, This will seem a bit off the wall, but I just noticed a discrepancy between the registers defined in the pci/if_rlreg.h directory and those specified on the RealTek datasheets for the antique RealTek 8139. In particular, as defined in the header, the registers in question are: #define RL_CFG0 0x0051 /* config register #0 */ #define RL_CFG1 0x0052 /* config register #1 */ #define RL_CFG2 0x0053 /* config register #2 */ #define RL_CFG3 0x0054 /* config register #3 */ #define RL_CFG4 0x0055 /* config register #4 */ #define RL_CFG5 0x0056 /* config register #5 */ The RealTek data sheets for the 8139, however, all indicate that these should be set to something like this: #define RL_CFG0 0x0051 /* config register #0 */ #define RL_CFG1 0x0052 /* config register #1 */ // No Config2 #define RL_CFG3 0x0059 /* config register #3 */ #define RL_CFG4 0x005A /* config register #4 */ #define RL_CFG5 0x00D8 /* config register #5 */ The datasheets I'm referencing are available here: http://realtek.info/pdf/ Specifically: http://realtek.info/pdf/rtl8139d.pdf http://realtek.info/pdf/rtl8139cp.pdf I believe the registers currently used apply to the 8169, but not necessarily the 8139 family -- can someone, hopefully easily, verify that the 8139 driver is using the right registers? The 8139 series may need the slightly different values used above to enable functionality like wake-on-lan. Thanks and regards, Matt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
On 02.02.2012 12:59, Коньков Евгений wrote: Здравствуйте, Andrey. Вы писали 2 февраля 2012 г., 8:35:23: AZ> On 02.02.2012 5:11, Alexander V. Chernikov wrote: On 01.02.2012 20:45, Andrey Zonov wrote: Hi, I'm trying to tune machine with 8.2-STABLE for heavy network load and now playing with netisr. Could anyone explain me why actually works only one netisr thread if I set them to 8? Can you please supply `nestat -Q` output and clarify you usage pattern ? (I mean, this is router/web server/some kind of traffic receiver/etc..). For example, flow policy does not balance traffic from single flow between different CPUs. AZ> This is a web server with multiple nginx instances. 5k/sec accepted AZ> connections. Input packet rate is 35kpps, output - 25kpps. AZ> I thought of changing policy for IP, but how can I do this (without AZ> patching)? Is it safe? AZ> netstat -Q (I turned on direct& direct force for now): AZ> Configuration: AZ> Setting Value Maximum AZ> Thread count 88 AZ> Default queue limit25610240 AZ> Direct dispatchenabled n/a AZ> Forced direct dispatch enabled n/a AZ> Threads bound to CPUs enabled n/a AZ> Protocols: AZ> Name Proto QLimit Policy Flags AZ> ip 1 5000 flow --- AZ> igmp 2256 source --- AZ> rtsock 3256 source --- AZ> arp7256 source --- AZ> ip6 10256 flow --- AZ> Workstreams: AZ> WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled AZ> 0 0 ip 0 0 1125716000 1125716 AZ> igmp 0 00000 AZ> rtsock 0 1000 102 102 AZ> arp0 0 27000 27 AZ> ip60 00000 AZ> 1 1 ip 0 0 1222701000 1222701 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 46000 46 AZ> ip60 00000 AZ> 2 2 ip 0 0 1184381000 1184381 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 45000 45 AZ> ip60 00000 AZ> 3 3 ip 0 0 1191094000 1191094 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 54000 54 AZ> ip60 00000 AZ> 4 4 ip 0 0 846165000 846165 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 19000 19 AZ> ip60 00000 AZ> 5 5 ip 0 0 849478000 849478 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 27000 27 AZ> ip60 00000 AZ> 6 6 ip 0 0 870836000 870836 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 0 29000 29 AZ> ip60 00000 AZ> 7 7 ip 0 5000 5943205 910862 3453459 4047784 AZ> igmp 0 00000 AZ> rtsock 0 00000 AZ> arp0 5 2100 109 130 AZ> ip60 10001 same problem, it is because one netisr take 100% so other threads stops?? to work fine. or packet scheduler has disbalanced scheduler and still trying to schedule packet to netisr:7 despite on it is 100% busy. Can you please try an attached patch? Rebuild kernel with this patch and set net.isr.dispatch to deferred / hybrid P.S. it is also reasonable to set net.isr.bindthreads to 1 -- WBR, Alexander Index: sys
Re: netisr defered - active only one thread
A multiqueue network card may help, like a dualport Intel igb E1G42ET. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: HowTo easy use IPFW
You are welcome to create a port and submit it for reccomendation... For that you should review the documents etc... at http://freebsd.org/docs Good Luck On Thu, Feb 02, 2012 at 11:33:14AM +0200, Коньков Евгений wrote: > this is the mine script which helps me keep my firewall very clean and safe. > > It is easy to understand even if you have a thousands rules, I think =) > > please comment. > > PS. If anybody may, please put into ports tree. thank you. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- ;s =; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re[2]: netisr defered - active only one thread
Здравствуйте, Adrian. Вы писали 2 февраля 2012 г., 18:09:33: AM> A multiqueue network card may help, like a dualport Intel igb E1G42ET. actually it is not. Intel have hardware separation to interrupts. So having only pptp trafic on interface cause next problem: only one thread process packets instead of 4 posible. -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
2012/2/2 Alexander V. Chernikov : > P.S. it is also reasonable to set net.isr.bindthreads to 1 I really don't recommend setting this in any release. There is currently a bug with binding kernel threads that causes unrelated threads to be unnecessarily bound to CPUs. In the specific case of net.isr.bindthreads this will cause(among others) the softclock threads to all be bound to the same CPU, which may well obviate any performance increase from binding the netisr threads. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
On 02.02.2012 21:07, Ryan Stone wrote: 2012/2/2 Alexander V. Chernikov: P.S. it is also reasonable to set net.isr.bindthreads to 1 I really don't recommend setting this in any release. There is currently a bug with binding kernel threads that causes unrelated threads to be unnecessarily bound to CPUs. In the specific case of net.isr.bindthreads this will cause(among others) the softclock threads to all be bound to the same CPU, which may well obviate any performance increase from binding the netisr threads. As far as I understand, the only effect of setting bindthreads to 1 causes intr_event_bind() to bind soft netisr to appropriate CPU. Can you point me to ML discussion or some other info clarifying this bug? Okay, so one can manually bind those netisrs to CPUs using `procstat -t 0` and cpuset -l X -t ... -- WBR, Alexander ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
On 02/02/12 19:16, Коньков Евгений wrote: Здравствуйте, Adrian. Вы писали 2 февраля 2012 г., 18:09:33: AM> A multiqueue network card may help, like a dualport Intel igb E1G42ET. actually it is not. Intel have hardware separation to interrupts. So having only pptp trafic on interface cause next problem: only one thread process packets instead of 4 posible. Andrey Zonov sed something about a "web server with multiple nginx instances". ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
On Thu, Feb 2, 2012 at 2:09 PM, Alexander V. Chernikov wrote: > As far as I understand, the only effect of setting bindthreads to 1 causes > intr_event_bind() to bind soft netisr to appropriate CPU. Can you point me > to ML discussion or some other info clarifying this bug? http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037597.html The intended behaviour is as you describe, unfortunately subsequent threads that are spawned in the intr process inherit the CPU affinity of the last netisr through to be bound to a CPU. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr defered - active only one thread
On Thu, Feb 2, 2012 at 2:51 PM, Ryan Stone wrote: > of the last netisr through to be bound to a CPU. *sigh*, that should read "netisr thread" of course. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: m_pullup - fail
The function does not allow access to data if m_flags & M_EXT size and more
MHLEN, although the data is actually available.
Why if there is no m_flags & M_PKTHDR size anyway MHLEN instead MLEN?
As an improvement, you can try to copy the data from the current m in
m_next, if m is not enough space and enough m_next (case m_flags & M_EXT).
If I figured out MBUF then m_pullup should take maximum length according to
this macro
#define M_PULLUP_MAX(m) \
((m)->m_flags & M_EXT ? \
(M_WRITABLE(m) ? (m)->m_ext.ext_size : 0) : \
(m)->m_flags & M_PKTHDR ? MHLEN : MLEN )
/usr/src/sys/sys/param.h:#define MSIZE 256 /* size of
an mbuf */
/usr/src/sys/sys/mbuf.h:#define MLEN(MSIZE - sizeof(struct
m_hdr)) /* normal data len */
/usr/src/sys/sys/mbuf.h:#define MHLEN (MLEN - sizeof(struct
pkthdr)) /* data len w/pkthdr */
#define M_EXT 0x0001 /* has associated external storage */
/*
* If first mbuf has no cluster, and has room for len bytes
* without shifting current data, pullup into it,
* otherwise allocate a new mbuf to prepend to the chain.
*/
if ((n->m_flags & M_EXT) == 0 &&
n->m_data + len < &n->m_dat[MLEN] && n->m_next) {
if (n->m_len >= len)
return (n);
m = n;
n = n->m_next;
len -= m->m_len;
} else {
if (len > MHLEN)
goto bad;
MGET(m, M_DONTWAIT, n->m_type);
if (m == NULL)
goto bad;
m->m_len = 0;
if (n->m_flags & M_PKTHDR)
M_MOVE_PKTHDR(m, n);
}
> -Original Message-
> From: Navdeep Parhar [mailto:npar...@gmail.com]
> Sent: Thursday, February 02, 2012 3:54 PM
> To: rozhuk...@gmail.com
> Cc: freebsd-net@freebsd.org
> Subject: Re: m_pullup - fail
>
> On Wed, Feb 1, 2012 at 11:07 AM, wrote:
> > Hello!
> >
> >
> > The function always returns an error and remove the chain MBUF for
> two
> > or more generated on the same host.
> > If the pre-call m_defrag no error occurs.
> > This is normal behavior?
> > How to know in advance the maximum size for MBUF that does not cause
> a
> > failure in m_pullup?
>
> You can't pullup more than MHLEN bytes into a pkthdr mbuf if it's not
> associated with an external cluster. See the last sentence in this
> excerpt from mbuf(9):
>
>m_pullup(mbuf, len)
>Arrange that the first len bytes of an mbuf chain are
> contiguous
>and lay in the data area of mbuf, so they are accessible
> with
>mtod(mbuf, type). It is important to remember that this may
>involve reallocating some mbufs and moving data so all
> pointers
>referencing data within the old mbuf chain must be
> recalculated or
>made invalid. Return the new mbuf chain on success, NULL on
> fail-
>ure (the mbuf chain is freed in this case). Note: It does
> not
>allocate any mbuf clusters, so len must be less than MHLEN.
>
> Regards,
> Navdeep
> >
> >
> > mbuf: 0xfe0074fc0600 len: 42, next: 0xfe0073a45800, 2
> > mbuf: 0xfe0073a45800 len: 210, next: 0, 1
> > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252
> >
> >
> >
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-
> unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: m_pullup - fail
I am writing a netgraph node for processing UDP packets passing through the router / bridge. Node must fully inspect the entire contents of the package, in some cases, change them. Node is connected to ng_ether (lower, upper). I was faced with the fact that all packets are processed normally, except for packets generated by the router / bridge that is larger than MHLEN. Packet from the network: mbuf: 0xfe00a9e27a00 len: 899, next: 0, 3 About the same package generated a router: mbuf: 0xfe00a4d59900 len: 42, next: 0xfe010a5c4000, 2 mbuf: 0xfe010a5c4000 len: 857, next: 0, 1 In this case m_pullup (m, m-> m_pkthdr.len) - returns NULL, though he could move 42 bytes to an external storage (ext) and remove the second mbuf (m_next). > -Original Message- > From: Julian Elischer [mailto:jul...@freebsd.org] > Sent: Thursday, February 02, 2012 3:25 PM > To: rozhuk...@gmail.com > Cc: freebsd-net@freebsd.org > Subject: Re: m_pullup - fail > > On 2/1/12 11:07 AM, rozhuk...@gmail.com wrote: > > Hello! > > > > > > The function always returns an error and remove the chain MBUF for > two > > or more generated on the same host. > > If the pre-call m_defrag no error occurs. > > This is normal behavior? > > How to know in advance the maximum size for MBUF that does not cause > a > > failure in m_pullup? > > > > send the list more information.. > like where it is being called from, or a stack trace, or what are you > trying to do? > > > mbuf: 0xfe0074fc0600 len: 42, next: 0xfe0073a45800, 2 > > mbuf: 0xfe0073a45800 len: 210, next: 0, 1 > > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > > > > > ___ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net- > unsubscr...@freebsd.org" > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
