mdp and ng_iface
Hi Mpd-netgraph remove ngX interface at exit but I need fixed interfaces. Is it possible to create option with which mpd will not send NGM_SHUTDOWN message to ng_iface node. -- Mikhail Yegorov e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PXE boot vs. DHCP
John Polstra wrote: > In article <002601c15cb4$064fb440$[EMAIL PROTECTED]>, > Cyrille Lefevre <[EMAIL PROTECTED]> wrote: > > "John Polstra" <[EMAIL PROTECTED]> wrote: > > > > > > Also, I don't feel that my patch is a hack. The entire purpose of > > > dhclient's PREINIT phase is to put the network interface into an > > > enabled state so that IP packets can be sent. If the interface is > > > already up, then it is already in that state. By failing to check the > > > interface first, the current dhclient-script needlessly destroys its > > > configuration and hangs the system. That is a bug, and my patch fixes > > > it. > > > > ok, did you ask the dhcp mailing list about that ? since, as a general rule, > > dhclient should be fixed for all platforms and not only for FreeBSD... > > No, I did not ask the DHCP mailing list about it. You are welcome > to do so if you wish. However, please note that (a) pxeboot is > FreeBSD-specific, and (b) dhclient-script is OS-specific by design. > > I have to say, I'm baffled as to why you are looking so hard for ways > to obstruct this simple bugfix. because I'm not sure this fix didn't cause any problem outside PXE. imagine you have a "normal" machine on which dhclient die for any reason. what's happen when you restart dhclient using your fix ? is everything always work all right ? did you try this case ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote: > Yes, you're right, I was mistaken in my paranioa, however you're > missing the fact that one may want to allocate an EXT buf and still > have it writeable. This is the function of M_RDONLY and M_WRITABLE framework which we put in place in -current about a year ago. I think we set things up so that sendfilebufs are not writable and so that custom external storage for jumbo ethernet frames are writeable. The changes were a bit big to port back to -stable. They involved moving external storage reference counts into the generic mbuf system. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Tue, Oct 23, 2001 at 06:57:59PM -0400, Bosko Milekic wrote:
> I believe that the correct way to deal with this issue is to have
> M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes
> that make up the leading space or trailing space, respectively,
> regardless of whether the underlying cluster/mbuf/ext_buf is marked
> writable or not.
The only problem I can see with this tack is that we might end up
with M_LEADINGSPACE macro which does something different to the
same macro in {Net,Open}BSD. I guess we should check what their
macros do at the moment.
When I looked at this question last year I think I found that there
were few enough places in the kernel which used M_LEADINGSPACE, so
it should be fairly easy to check them. However, I think several
of the uses were in KAME code.
(I did have some notes on this work, but unfortunately the hard
drive with them on whet south recently...)
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
Hi, I am one of the KAME members.
> The only problem I can see with this tack is that we might end up
> with M_LEADINGSPACE macro which does something different to the
> same macro in {Net,Open}BSD. I guess we should check what their
> macros do at the moment.
Right. And we will have a problem if someone changes the semantics of
M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same
as the current FreeBSD does, that is, returns 0 if M_EXT is set.
> When I looked at this question last year I think I found that there
> were few enough places in the kernel which used M_LEADINGSPACE, so
> it should be fairly easy to check them. However, I think several
> of the uses were in KAME code.
The patch posted first by Luigi is safe because the patch doesn't
change any semantics of M_LEADINGSPACE. I think it (and the patch)
reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is
not writable and the real space when the mbuf (cluster) is writable.
But, I disagree the later proposal from Bosko that changes the meaning
of M_LEADINGSPACE. This leads more ifdefs in the shared code
(ex. KAME, maybe other cross-platform projects) and the code
complexity.
---
Keiichi SHIMA
IIJ Research Laboratory <[EMAIL PROTECTED]>
KAME Project <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
> > When I looked at this question last year I think I found that there
> > were few enough places in the kernel which used M_LEADINGSPACE, so
> > it should be fairly easy to check them. However, I think several
> > of the uses were in KAME code.
> The patch posted first by Luigi is safe because the patch doesn't
> change any semantics of M_LEADINGSPACE. I think it (and the patch)
> reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is
> not writable and the real space when the mbuf (cluster) is writable.
So the M_LEADINGSPACE macro should probaly read:
#define M_LEADINGSPACE(m) \
(!M_WRITABLE(m) ? 0 :\
(m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \
(m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
(m)->m_data - (m)->m_dat)
and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note
the inconsistancy where M_LEADINGSPACE returns the number of writable
bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate
if they are writable or not.
Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros
with consistant behaviour. The _R macros would be cheaper 'cos
they wouldn't have to check writability. These could be used in
the case where you already know the storage is writable.
(Here _R would mean "regardless" 'cos it's hard to imagine a
situation where you want to know how many readable bytes are outside
the valid data region in an mbuf ;-)
Bosko - what do you think of modifying M_LEADINGSPACE as shown
above and then providing these new macros? It would mean that we
can leave shared code alone, but where we want to optimise
M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
In message <[EMAIL PROTECTED]>, David Malone writes:
>
>So the M_LEADINGSPACE macro should probaly read:
>
>#defineM_LEADINGSPACE(m)
> \
> (!M_WRITABLE(m) ? 0 : \
> (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \
> (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
> (m)->m_data - (m)->m_dat)
Yes, I think this is cleaner than the version that was just committed
to -stable, and it could have been committed to -current and MFC'd
in the normal way without changes. I really doubt that it is worth
splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE.
>Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros
>with consistant behaviour. The _R macros would be cheaper 'cos
>they wouldn't have to check writability. These could be used in
>the case where you already know the storage is writable.
This optimisation seems the only reason why it might make sense to
change the current semantics of M_LEADINGSPACE to ignore writeability,
and I'm not sure that even this is worthwhile. While the word
'space' does not necessarily imply 'writable space', why would
anything ask for the leading or trailing space if writing to it
was not being considered?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
Hi Keiichi, On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ? wrote: > Hi, I am one of the KAME members. so i have a question for you -- the next step on this kind of optimizations is to avoid that m_pullup() allocates an mbuf when data is already contiguous and in a writable (non-shared) cluster. Garret was suggesting a new interface for this, at the beginning i thought the same, but now i am a bit uncertain on whether it is really necessary to use a different interface, or whether this would cause compatibility problems with other BSD's. Maybe you have already thought about this issue while developing the KAME code, and can say something on the topic ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, Oct 26, 2001 at 01:28:29PM +0100, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, David Malone writes: > > > >So the M_LEADINGSPACE macro should probaly read: > > > >#define M_LEADINGSPACE(m) > > \ > > (!M_WRITABLE(m) ? 0 : \ > > (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \ > > (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ > > (m)->m_data - (m)->m_dat) > > Yes, I think this is cleaner than the version that was just committed > to -stable, and it could have been committed to -current and MFC'd > in the normal way without changes. I really doubt that it is worth > splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE. gcc -O seems to agree with you :) This form produces a kernel which is 32 bytes shorter than the form that I committed (out of 1Meg, so not really a big deal). cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > Right. And we will have a problem if someone changes the semantics of > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > as the current FreeBSD does, that is, returns 0 if M_EXT is set. > > > When I looked at this question last year I think I found that there > > were few enough places in the kernel which used M_LEADINGSPACE, so > > it should be fairly easy to check them. However, I think several > > of the uses were in KAME code. > > The patch posted first by Luigi is safe because the patch doesn't > change any semantics of M_LEADINGSPACE. I think it (and the patch) > reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is > not writable and the real space when the mbuf (cluster) is writable. > > But, I disagree the later proposal from Bosko that changes the meaning > of M_LEADINGSPACE. This leads more ifdefs in the shared code > (ex. KAME, maybe other cross-platform projects) and the code > complexity. Just because M_LEADINGSPACE may be broken in the other systems does not mean that it should be broken in our system as well. I am against sacrificying good code in order to deal with the left-over stupidities (pardon the seemingly harsh vocabulary) in the other systems, when it comes to porting. You should understand that M_LEADINGSPACE was meant to return the number of leading bytes in the underlying data buffer and that it was only broken when someone decided to half-implement ext bufs. This brokeness happened to live on in present-day systems and unbreaking it should not be put on hold for the sake of pseudo-compatibility, IMHO. > --- > Keiichi SHIMA > IIJ Research Laboratory <[EMAIL PROTECTED]> > KAME Project <[EMAIL PROTECTED]> > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, Oct 26, 2001 at 01:10:34PM +0100, David Malone wrote:
> So the M_LEADINGSPACE macro should probaly read:
>
> #define M_LEADINGSPACE(m) \
>(!M_WRITABLE(m) ? 0 : \
> (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \
> (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
> (m)->m_data - (m)->m_dat)
>
> and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note
> the inconsistancy where M_LEADINGSPACE returns the number of writable
> bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate
> if they are writable or not.
>
> Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros
> with consistant behaviour. The _R macros would be cheaper 'cos
> they wouldn't have to check writability. These could be used in
> the case where you already know the storage is writable.
>
> (Here _R would mean "regardless" 'cos it's hard to imagine a
> situation where you want to know how many readable bytes are outside
> the valid data region in an mbuf ;-)
>
> Bosko - what do you think of modifying M_LEADINGSPACE as shown
> above and then providing these new macros? It would mean that we
> can leave shared code alone, but where we want to optimise
> M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so.
I already stated what I thought about it: it's wrong for reasons
mentionned in previous Emails. It means that we will be adding support
for a broken macro, not to mention enlarging the macro, which is bad
especially for code that is actually using it properly.
> David.
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
Bosko, Keiichi has a valid point. The semantics of an interface are described by the documentation associated with it, not by its name or the Oxford Dictionary. As much as it might be misleading that M_LEADINGSPACE checks for writability, it has probably been like this for a long time, we have plenty of code that depends on this, and people looking for documentation will likely see this behaviour documented. Changing it might introduce insidious bugs in the code -- because in reality, clusters are almost never shared except for those on the TCP send queue and for multicast packets (but who uses multicast, anyways), so there is a chance that we will have buggy code that goes unnoticed for a long time. cheers luigi On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > Right. And we will have a problem if someone changes the semantics of > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same ... > > But, I disagree the later proposal from Bosko that changes the meaning > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > (ex. KAME, maybe other cross-platform projects) and the code > > complexity. > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > --- > > Keiichi SHIMA > > IIJ Research Laboratory <[EMAIL PROTECTED]> > > KAME Project <[EMAIL PROTECTED]> > > > > -- > Bosko Milekic > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote: > Bosko, Keiichi has a valid point. The semantics of an interface > are described by the documentation associated with it, not by its > name or the Oxford Dictionary. And what documentation would that be? Are you referring to the [incomplete] mbuf(9) man page which does not cover M_LEADINGSPACE, or are you referring to "The Implementation of 4.4BSD" (McKusick et al.) which, to my knowledge, doesn't specify anything regarding the writability of the underlying data (I don't know if it specifies anything regarding M_LEADINGSPACE to begin with)? The M_LEADINGSPACE macro always had the line of code that would return the leading space even for ext_bufs commented out, suggesting that the code did exist in the original implementation or was intended to. You yourself noticed that the behavior of M_LEADINGSPACE was incorrect in that it returned 0 for all ext_bufs. Therefore, the issue is not whether or not M_LEADINGSPACE should be changed because, clearly, it should and you yourself are lobbying to change it. The issue is how to change it properly, and I have already presented my opinion on how it should be done. Arguing that OpenBSD and/or NetBSD don't have this behavior is totally ridiculous, seeing as how they don't have the same "writability" macros (the last time I checked) that we do anyway. > As much as it might be misleading that M_LEADINGSPACE checks for > writability, it has probably been like this for a long time, we > have plenty of code that depends on this, and people looking for > documentation will likely see this behaviour documented. Changing No. It has never been like this. > it might introduce insidious bugs in the code -- because in reality, > clusters are almost never shared except for those on the TCP send > queue and for multicast packets (but who uses multicast, anyways), > so there is a chance that we will have buggy code that goes unnoticed > for a long time. > > cheers > luigi > > On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > > Right. And we will have a problem if someone changes the semantics of > > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > ... > > > But, I disagree the later proposal from Bosko that changes the meaning > > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > > (ex. KAME, maybe other cross-platform projects) and the code > > > complexity. > > > > Just because M_LEADINGSPACE may be broken in the other systems does > > not mean that it should be broken in our system as well. I am against > > sacrificying good code in order to deal with the left-over stupidities > > (pardon the seemingly harsh vocabulary) in the other systems, when it > > comes to porting. > > You should understand that M_LEADINGSPACE was meant to return the > > number of leading bytes in the underlying data buffer and that it was > > only broken when someone decided to half-implement ext bufs. This > > brokeness happened to live on in present-day systems and unbreaking it > > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > > > --- > > > Keiichi SHIMA > > > IIJ Research Laboratory <[EMAIL PROTECTED]> > > > KAME Project <[EMAIL PROTECTED]> > > > > > > > -- > > Bosko Milekic > > [EMAIL PROTECTED] > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, Oct 26, 2001 at 01:38:27PM -0400, Bosko Milekic wrote: > On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote: > > Bosko, Keiichi has a valid point. The semantics of an interface > > are described by the documentation associated with it, not by its > > name or the Oxford Dictionary. > > And what documentation would that be? Are you referring to the Probably Stevens vol.2 comments that in depth. But mostly, we have legacy code (which is a form of documentation), and the other BSDs. Point is, i could make the one-line commit in mbuf.h and go to bed without being worried of breaking the kernel, whereas the change you have in mind would require you a scrutiny of the whole code to make sure that noone is depending on the writability check. Don't misunderstand me, in principle you are right, but in practice having the same interface with two different semantics in different OS is a recipe for trouble. Microsoft has done something similar with their socket API (at least for multicast, anyways), where primitives have a slightly different semantics and/or parameters in Windows than in Unix, and I, and am sure others, have wasted hours and hours tracking portability bugs of this kind. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- > [incomplete] mbuf(9) man page which does not cover M_LEADINGSPACE, or > are you referring to "The Implementation of 4.4BSD" (McKusick et al.) > which, to my knowledge, doesn't specify anything regarding the > writability of the underlying data (I don't know if it specifies > anything regarding M_LEADINGSPACE to begin with)? > The M_LEADINGSPACE macro always had the line of code that would return > the leading space even for ext_bufs commented out, suggesting that the > code did exist in the original implementation or was intended to. You > yourself noticed that the behavior of M_LEADINGSPACE was incorrect in > that it returned 0 for all ext_bufs. Therefore, the issue is not whether > or not M_LEADINGSPACE should be changed because, clearly, it should and > you yourself are lobbying to change it. The issue is how to change it > properly, and I have already presented my opinion on how it should be > done. Arguing that OpenBSD and/or NetBSD don't have this behavior is > totally ridiculous, seeing as how they don't have the same "writability" > macros (the last time I checked) that we do anyway. > > > As much as it might be misleading that M_LEADINGSPACE checks for > > writability, it has probably been like this for a long time, we > > have plenty of code that depends on this, and people looking for > > documentation will likely see this behaviour documented. Changing > > No. It has never been like this. > > > it might introduce insidious bugs in the code -- because in reality, > > clusters are almost never shared except for those on the TCP send > > queue and for multicast packets (but who uses multicast, anyways), > > so there is a chance that we will have buggy code that goes unnoticed > > for a long time. > > > > cheers > > luigi > > > > On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > > > On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > > > Right. And we will have a problem if someone changes the semantics of > > > > M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same > > ... > > > > But, I disagree the later proposal from Bosko that changes the meaning > > > > of M_LEADINGSPACE. This leads more ifdefs in the shared code > > > > (ex. KAME, maybe other cross-platform projects) and the code > > > > complexity. > > > > > > Just because M_LEADINGSPACE may be broken in the other systems does > > > not mean that it should be broken in our system as well. I am against > > > sacrificying good code in order to deal with the left-over stupidities > > > (pardon the seemingly harsh vocabulary) in the other systems, when it > > > comes to porting. > > > You should understand that M_LEADINGSPACE was meant to return the > > > number of leading bytes in the underlying data buffer and that it was > > > only broken when someone decided to half-implement ext bufs. This > > > brokeness happened to live on in present-day systems and unbreaking it > > > should not be put on hold for the sake of pseudo-compatibility, IMHO. > > > > > > > --- > > > > Keiichi SHIMA > > > > IIJ Research Laboratory <[EMAIL PROTECTED]> > > > > KAME Project <[EMAIL PROTECTED]> > > > > > > > > > > -- > > > Bosko Milekic > > > [EMAIL PROTECTED] > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to [E
Re: performance issues with M_PREPEND on clusters
Hi, Bosko. Bosko Milekic wrote: > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. I agree with you at the point that the good code should be accepted. With Luigi's patch, we will get more performance than before. It makes us possible to use the leading space (they were unusable before the patch) to prepend some lower-layer packet headers with no changes of existing code. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. M_LEADINGSPACE might be meant to return as you were saying. But because of some reasons (maybe a lack of time to implement the complete code), it behaves as we see now. For a long time, in many systems, M_LEADINGSPACE had been returning writable space only. As a result, some codes (including KAME) rely on the behavior. So, I would suggest that we should not change M_LEADINGSPACE behavior, and write some documents (or comment in the source may be enough) about that. Because one of the reasons of the confusion of M_LEADINGSPACE is there were no documentation about that, we had only the code and the code said that it returns a writable length. (if necessary) we should create a new API to get the real(?) space as David have proposed. Best regards, --- Keiichi SHIMA IIJ Research Laboratory <[EMAIL PROTECTED]> KAME Project <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Sat, Oct 27, 2001 at 03:31:48AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > M_LEADINGSPACE might be meant to return as you were saying. But > because of some reasons (maybe a lack of time to implement the > complete code), it behaves as we see now. For a long time, in many > systems, M_LEADINGSPACE had been returning writable space only. As a > result, some codes (including KAME) rely on the behavior. This is not true. M_LEADINGSPACE has not been returning writable space only for a long time; it has been returning space in non-M_EXT mbufs for a long time. So, doing what you want to do *is* changing its behavior, whether you like it or not. I don't know how many times I have to repeat this until someone starts to get it. The issue is not whether or not you're changing the behavior of M_LEADINGSPACE because Luigi's suggestion obviously does. The issue is how to do it properly and the way it's being proposed right now is not the proper way. As it turns out, I'm really not up for extending this debate any longer. I'm not going to kill myself because something like this is being done wrongly, seeing as how I'm the only one arguing this side (according to the response hits, it appears I'm alone with this opinion), although I will maintain that I believe it is wrong, and for good reason, but I may end up eventually beating myself up if I have to repeat the same thing over and over again in the same thread. > So, I would suggest that we should not change M_LEADINGSPACE behavior, > and write some documents (or comment in the source may be enough) > about that. Because one of the reasons of the confusion of > M_LEADINGSPACE is there were no documentation about that, we had only > the code and the code said that it returns a writable length. > > (if necessary) we should create a new API to get the real(?) space as > David have proposed. > > Best regards, > > --- > Keiichi SHIMA > IIJ Research Laboratory <[EMAIL PROTECTED]> > KAME Project <[EMAIL PROTECTED]> -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
Hi Bosko, Bosko Milekic wrote: > > > M_LEADINGSPACE might be meant to return as you were saying. But > > because of some reasons (maybe a lack of time to implement the > > complete code), it behaves as we see now. For a long time, in many > > systems, M_LEADINGSPACE had been returning writable space only. As a > > result, some codes (including KAME) rely on the behavior. > > This is not true. M_LEADINGSPACE has not been returning writable space > only for a long time; it has been returning space in non-M_EXT mbufs for > a long time. Ah, I'm sorry, I was wrong. As you said, M_LEADINGSPACE returns 0 even if there are writable space before the data part of the mbuf cluster. Please note that I'm not saying you are wrong (maybe you are correct in theory). But there is a code (not only our code but others maybe..) relys on the current behaviour. Changing M_LEADINGSPACE return the writable space will not introduce any compatibility issues, while changing M_LEA... return the exact (writable or readonly) space will cause compatibility issue. I'm worring about that... > So, doing what you want to do *is* changing its behavior, > whether you like it or not. I don't know how many times I have to repeat > this until someone starts to get it. The issue is not whether or not > you're changing the behavior of M_LEADINGSPACE because Luigi's > suggestion obviously does. The issue is how to do it properly and the > way it's being proposed right now is not the proper way. > As it turns out, I'm really not up for extending this debate any > longer. I'm not going to kill myself because something like this is > being done wrongly, seeing as how I'm the only one arguing this side > (according to the response hits, it appears I'm alone with this > opinion), although I will maintain that I believe it is wrong, and for > good reason, but I may end up eventually beating myself up if I have to > repeat the same thing over and over again in the same thread. --- Keiichi SHIMA IIJ Research Laboratory <[EMAIL PROTECTED]> KAME Project <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Windows XP pro
Hello fellow FreeBSD users! Is WinXP compatible with FreeBSD / samba? I mean, with Windows 2000 pro I always could connect to my FreeBSD shares. But if I try to make a connection from my Windows XP box I get the message: The account is not allowd to connect from this station. How does one solve this? In Samba I have turned encrypted passwords ON, because it was compatible with Windows 2000. Has anyone else made successful drive mapping between Windows XP and FreeBSD/Samba?? Greets, Marcel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
> The M_LEADINGSPACE macro always had the line of code that would return >the leading space even for ext_bufs commented out, suggesting that the >code did exist in the original implementation or was intended to. The M_LEADINGSPACE macro was introduced in rev 7.11 of mbuf.h, in August 1988, at the same time as the "new" mbufs, i.e. when external sotrage was introduced, m_act renamed to m_nextpkt, etc. Perhaps the commented code is there to remind what the right thing to do is once you can tell whether or not external storage is writable. I don't think it's reasonable to say that the presence of the comment makes it completely obvious what the intentions of this code were in 1988. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Port-based routing?
Hi, Is there a way in FreeBSD to route packets based on the destination port number? (I'm asking this on behalf of a friend, not for myself.) This is the setup: There are two uplinks, the first is via a ADSL connection (ppp running on tun0, using PPPoE), the second is via a normal ethernet interface (dc0, which has a slower SDSL router connected). They have different IP addresses, of course. Now he would like to direct web traffic (i.e. port 80) to tun0, and everything else to dc0. Is this possible with FreeBSD at all? Thanks in advance for any hint and advice! Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: performance issues with M_PREPEND on clusters
On Fri, 26 Oct 2001, Luigi Rizzo wrote: ... > documentation will likely see this behaviour documented. Changing it > might introduce insidious bugs in the code -- because in reality, > clusters are almost never shared except for those on the TCP send queue > and for multicast packets (but who uses multicast, anyways), so there is > a chance that we will have buggy code that goes unnoticed for a long > time. ... I use multicast on my workstation pretty much every day. While my own box isn't a multicast router, we have several FreeBSD boxes deployed as multicast routers at NAI Labs that are also used daily. Sure is a lot cheaper than the commercial video-conferencing services, and as long as you use telephone conferencing for the audio, it even sounds good too :-). No comment on the technical work going on here intended, just wanted to observe that people actually do use multicast :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
