Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Apr 2000 13:40:49 -0700
From:      "Wilbert de Graaf" <wilbertdg@hetnet.nl>
To:        "FreeBSD-hackers" <FreeBSD-hackers@FreeBSD.ORG>
Subject:   Refresh a list that could be used
Message-ID:  <007501bfa3f6$556cf6f0$fec92080@alias>

next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.

------=_NextPart_000_006F_01BFA3BB.8C424B70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

As part of an IGMPv3 implementation on FreeBSD I had to add a list to a =
datastructure (in_multi). This list can be set by users (using ioctl) =
and be replaced later. While replacing this list, there is the =
possibility (ad1) of a concurrent reader (the process when an incoming =
packet has to be passed to a socket). So just replacing this list and =
deleting the old one makes no sense.

There could think of two ways to implement this:
1) a locking strategy: lock when updating and while being used ... =
however, this slows down the process of incoming packets
-or-
2) simply save the old list, and delete it at the next replacement of =
the list (ad 2)

Or is there a common strategy in FreeBSD to handle a situation like this =
? Could anybody comment on this.=20

Thanks, Wilbert

Ad 1)

It is true that this replacement of the list will *not* preempt in this =
case since the reader is delivery of an ip packet to a socket, which is =
done at splnet(), while this routine doesn't even use splimp(). But this =
precaution is just to make sure it will be safe in the case of =
multi-processors. Or did I miss something ?

Ad 2)

struct in_multi {
    ...
    struct isf_entry *inm_sflist, *inm_sfoldlist;        /* source =
filter list */
    ...
};

While replacing the list, the old one is stored in inm_sfoldlist, so =
current readers won't be harmed by invalid pointers while deleting the =
list. At a next replacement, the old list is simply deleted since the =
assumption is really valid that there won't be any readers of the old =
list. (Not eve when a multi-threaded program starts to fool around with =
the filterlist).

Btw. There will be a hashing schema over this structure, to determine =
whether a source ip is in the set.


------=_NextPart_000_006F_01BFA3BB.8C424B70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As part of an IGMPv3 implementation on =
FreeBSD I=20
had to add a list to a datastructure (in_multi). This list can be set by =
users=20
(using ioctl) and&nbsp;be replaced later.</FONT><FONT face=3DArial =
size=3D2> While=20
replacing this list, there is the possibility (ad1) of a concurrent =
reader (the=20
process when an incoming packet has to be passed to&nbsp;a socket). So =
just=20
replacing this list and deleting the old one makes no =
sense.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There could think of two ways to =
implement=20
this:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1) a locking strategy: lock when =
updating and while=20
being used ... however, this slows down the process of incoming=20
packets</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-or-</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) simply save the old list, and delete =
it at the=20
next replacement of the list (ad 2)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Or is there a common strategy in =
FreeBSD to handle=20
a&nbsp;situation like this ? Could anybody comment on this. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,&nbsp;Wilbert</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Ad 1)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>It is true that this&nbsp;replacement =
of the=20
list&nbsp;will *not* preempt in this case since the reader =
is&nbsp;delivery of=20
an ip packet to a socket, which is&nbsp;done at splnet(), while this =
routine=20
doesn't even use splimp(). But this precaution is just to make sure it =
will be=20
safe in the case of multi-processors. Or did I miss something =
?</FONT></DIV>
<DIV>&nbsp;</DIV>Ad 2)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>struct in_multi {</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; ...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; struct isf_entry =
*inm_sflist,=20
*inm_sfoldlist;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; /* source filter =
list=20
*/</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; ...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>};</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>While replacing the list, the old one =
is stored in=20
inm_sfoldlist, so current readers won't be harmed by invalid pointers =
while=20
deleting the list. At a next replacement, the old list is simply deleted =
since=20
the assumption is really valid that there won't be any readers of the =
old list.=20
(Not eve when a multi-threaded program starts to fool around with the=20
filterlist).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Btw. There will be a hashing schema =
over this=20
structure, to determine whether a source ip is in the set.</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006F_01BFA3BB.8C424B70--



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007501bfa3f6$556cf6f0$fec92080>