From owner-freebsd-hackers Tue Apr 11 12:53:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hetnet.nl (net014s.hetnet.nl [194.151.104.154]) by hub.freebsd.org (Postfix) with ESMTP id 5A71337B755 for ; Tue, 11 Apr 2000 12:53:21 -0700 (PDT) (envelope-from wilbertdg@hetnet.nl) Received: from alias ([38.28.76.12]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.327.32); Tue, 11 Apr 2000 21:53:04 +0200 Message-ID: <007501bfa3f6$556cf6f0$fec92080@alias> From: "Wilbert de Graaf" To: "FreeBSD-hackers" Subject: Refresh a list that could be used Date: Tue, 11 Apr 2000 13:40:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01BFA3BB.8C424B70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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

Hi,

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 be replaced later. 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 a socket). So = just=20 replacing this list and deleting the old one makes no = sense.

There could think of two ways to = implement=20 this:

1) a locking strategy: lock when = updating and while=20 being used ... however, this slows down the process of incoming=20 packets

-or-

2) simply save the old list, and delete = it at the=20 next replacement of the list (ad 2)

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

Thanks, Wilbert

Ad 1)

It is true that this replacement = of the=20 list will *not* preempt in this case since the reader = is delivery of=20 an ip packet to a socket, which is 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 = ?

Ad 2)

struct in_multi {

...

struct isf_entry = *inm_sflist,=20 *inm_sfoldlist; /* source filter = list=20 */

...

};

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).

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

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