Hi Luigi,
Luigi Rizzo wrote:
>
> 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 beg
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 u
> 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 t
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
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_LEAD
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
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.
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
[i
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 pl
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
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.
>
> >
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 :
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 (
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 ?
> > 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
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
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,
> rega
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
Luigi Rizzo <[EMAIL PROTECTED]> said:
>On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote:
>> ... the whole purpose of m_pullup is to
>> *guarantee* that the data in question will never be shared.
>
>Technically, it is correct that m_pullup guarantees that the data
>in question will
As I have stated to Luigi in private and as I have stated more than
half a year ago now when this issue was first brought up by dwmalone,
I believe that the correct way to deal with this issue is to have
M_LEADINGSPACE and M_TRAILINGSPACE simply return the number o
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.
Yes, but this is the sort of things that are better sorted out
in -cur
On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote:
> < said:
>
> > Similar things could be done in m_pullup() to avoid the
> > extra allocation.
>
> Can't be done in m_pullup: the whole purpose of m_pullup is to
> *guarantee* that the data in question will never be shared. It migh
* Luigi Rizzo <[EMAIL PROTECTED]> [011023 13:50] wrote:
> On Tue, Oct 23, 2001 at 01:28:13PM -0500, Alfred Perlstein wrote:
> ...
> > > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is
> > > set, instead of calling the second part of M_WRITABLE to check
> > > whether there is a chan
On Tue, Oct 23, 2001 at 01:28:13PM -0500, Alfred Perlstein wrote:
...
> > In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is
> > set, instead of calling the second part of M_WRITABLE to check
> > whether there is a chance of writing into the cluster. This means
...
> I've seen this br
* Alfred Perlstein <[EMAIL PROTECTED]> [011023 13:28] wrote:
> * Luigi Rizzo <[EMAIL PROTECTED]> [011023 13:06] wrote:
> >
> > Hi,
> > don't know what is the right forum to discuss this, but this is
> > certainly one. I have also Bcc-ed some people who might need to be
> > involved.
> >
> > In t
* Luigi Rizzo <[EMAIL PROTECTED]> [011023 13:06] wrote:
>
> Hi,
> don't know what is the right forum to discuss this, but this is
> certainly one. I have also Bcc-ed some people who might need to be
> involved.
>
> In the mbuf code, M_LEADINGSPACE always returns 0 when M_EXT is
> set, instead of
26 matches
Mail list logo
