Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 12:29 AM, Jack Vogel wrote: > [...] > If you notice, the Linux driver did not enable multiqueue on the hardware > either, so do you think a whole department of software engineers backed > by the hardware engineers who designed the damn thing might have had > a reason? > Let's find out :-) In the mean time, as a hacker, I'd be interested to know why the NVM ships with MSI_X_NUM == 2 at offset 0x1b when the datasheet say it does support up value to 4 ? This might be as simple as "the hardware needs special wiring to support 5 vectors.", or whatever... > IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and > tried it for a while just because I could, implementing the code was not > difficult. Over time however that code proved to be a source of instability > and thus was disabled. > It would be interesting for the records to have this information public, especially the kind of instability seen. > I have heard a rumor that the Linux crew may actually be trying a second > time to make it work, and that might give me cause to look at it again too, > but its not clear if I'll have time with other priorities. > ack. Now, what about header-split support in em(4) ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: buf_ring(9) API precisions
Hi,
On Fri, Sep 16, 2011 at 10:41 AM, K. Macy wrote:
> On Fri, Sep 16, 2011 at 3:02 AM, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Wed, Sep 14, 2011 at 10:53 PM, Arnaud Lacombe wrote:
>>> Hi Kip,
>>>
>>> I've got a few question about the buf_ring(9) API.
>>>
>>> 1) what means the 'drbr_' prefix. I can guess the two last letter, 'b'
>>> and 'r', for Buffer Ring, but what about 'd' and 'r' ?
>>>
>>> 2) in `sys/sys/buf_ring.h', you defined 'struct buf_ring' as:
>>>
>>> struct buf_ring {
>>> volatile uint32_t br_prod_head;
>>> volatile uint32_t br_prod_tail;
>>> int br_prod_size;
>>> int br_prod_mask;
>>> uint64_t br_drops;
>>> uint64_t br_prod_bufs;
>>> uint64_t br_prod_bytes;
>> shouldn't those 3 fields be updated atomically, especially on 32bits
>> platforms ? That might pose a problem as, AFAIK, FreeBSD do not have
>> MI 64bits atomics operations...
>
> Between the point at which br_prod_tail == prod_head and when we
> update br_prod_tail to point to prod_next we are the exclusive owners
> of the fields in buf_ring. That is why we wait for any other
> enqueueing threads to update br_prod_tail to point to prod_head before
> continuing.
>
How do you enforce ordering ? I do not see anything particular
forbidding the `br->br_prod_tail' to be committed first, leading other
thread to believe they have access to the statistics, while the other
thread has not yet committed its change.
Thanks,
- Arnaud
> Cheers
>
> /*
> * If there are other enqueues in progress
> * that preceeded us, we need to wait for them
> * to complete
> */
> while (br->br_prod_tail != prod_head)
> cpu_spinwait();
> br->br_prod_bufs++;
> br->br_prod_bytes += nbytes;
> br->br_prod_tail = prod_next;
> critical_exit();
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo wrote: > On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: >> > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: >> >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> >> Hi list, >> >> >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this >> >> >> mean that >> >> >> driver (and chip) do not support IP TX checksum offload or the support >> >> >> for >> >> >> TX is not yet included in the driver? >> > ... >> >> This is slightly off-topic, but still.. >> >> >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> >> has been implemented in the driver. As per the product brief, the >> > ... >> >> [0]: the commit message say "performance was not good", but it is not >> >> the driver's developer to decide whether or not a feature is good or >> >> not. The developer's job is to implement the chip capabilities, and >> >> let it to the user to enable or disable the capabilities. At best, the >> >> developer can decide whether or not to enable the feature by default. >> > >> > actually, this is a perfect example where the developer has done the >> > right thing: implemented the feature, verified that performance is bad, >> > hence presumably removed support for the feature from the code (which also >> > means that the normal code path will run faster because there are no >> > run-time decisions to be made). >> > >> > "optional" features are often costly even when disabled. >> > >> I forgot to mention that in this case, the code full of >> EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with >> the multiqueue's architecture. The only thing removed is a conditional >> and an assignation in the driver's attachment which was enabling the >> feature, ie. the cost you point out is still paid today, without any >> benefit. > > the above suggests that you have a wonderful opportunity: with just > a little bit of time and effort you should be able to complete/re-enable > the missing code, run tests that you believe significant (given > your statement below) and prove or disprove the comment about > performance. > Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
.. and believe me, lots of people will appreciate it if you can verify/diagnose issues. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: > > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> >> Hi list, > >> >> > >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload > >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean > >> >> that > >> >> driver (and chip) do not support IP TX checksum offload or the support > >> >> for > >> >> TX is not yet included in the driver? > > ... > >> This is slightly off-topic, but still.. > >> > >> FWIW, I'm not really impressed by what chips claim to support vs. what > >> has been implemented in the driver. As per the product brief, the > > ... > >> [0]: the commit message say "performance was not good", but it is not > >> the driver's developer to decide whether or not a feature is good or > >> not. The developer's job is to implement the chip capabilities, and > >> let it to the user to enable or disable the capabilities. At best, the > >> developer can decide whether or not to enable the feature by default. > > > > actually, this is a perfect example where the developer has done the > > right thing: implemented the feature, verified that performance is bad, > > hence presumably removed support for the feature from the code (which also > > means that the normal code path will run faster because there are no > > run-time decisions to be made). > > > > "optional" features are often costly even when disabled. > > > I forgot to mention that in this case, the code full of > EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with > the multiqueue's architecture. The only thing removed is a conditional > and an assignation in the driver's attachment which was enabling the > feature, ie. the cost you point out is still paid today, without any > benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. cheers luigi > > Now I might also openly question the test method used by the folks at > Intel, just seeing how much issue I've had with the driver (I still > have for some, even if not driver related), which have not been > reproduced there. > > Finally, when someone say "performance are better that way", the first > thing I'd be tempted to ask is: "What is your test ? How did you > collects the numbers ? How did you reach the conclusion ?". None of > this stuff is public. > regards, > - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: checksum offload
On Sun, Sep 18, 2011 at 5:23 PM, Dieter BSD wrote: >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that >> driver (and chip) do not support IP TX checksum offload or the support for >> TX is not yet included in the driver? > > The first question is "is checksum offload a good idea?" > There is less protection against errors. This assumes firmware flaws, right? Albeit, it also does confuse some software like tcpdump. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: checksum offload
> The data sheet for intel 82576 advertises IP TX/RX checksum offload > but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that > driver (and chip) do not support IP TX checksum offload or the support for > TX is not yet included in the driver? The first question is "is checksum offload a good idea?" There is less protection against errors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Mixing Asynchronous Network I/O and POSIX Threads
Why not just port to using libevent 2.x with the thread support, and thus be portable to all platforms? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Mixing Asynchronous Network I/O and POSIX Threads
Dear Jilles, I am using sigwaitinfo() with all interrupts masked to avoid the possibility of race conditions in signal handlers, but I have not used any realtime signals. Linux 2.6.35 found a way to invoke the SIGIO handler despite it being masked, but that issue would not occur under production conditions and that is a bug for a different mailing list. Being unable to F_SETOWN individual threads would cause problems because it causes network traffic to become serialized. My code must run on Linux, but if I were to write FreeBSD-specific code so it would also work on FreeBSD, would using kqueue enable me to specify which threads handle events on specific file descriptors? Yours truly, Richard Yao On Sun, Sep 18, 2011 at 3:44 PM, Jilles Tjoelker wrote: > On Sun, Sep 18, 2011 at 11:32:08AM -0400, Richard Yao wrote: >> I wrote a program for Linux that uses Asynchronous Network I/O and >> POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to >> specify which thread handles each connection's SIGIO interrupts. >> gettid() is Linux-specific and I would prefer to do this in a way that >> also works with FreeBSD. Is that possible? > > In FreeBSD, you can only F_SETOWN processes or process groups, not > threads, so a direct port is probably not possible. Another Linux > feature not in FreeBSD is F_SETSIG (to send a realtime signal instead of > SIGIO and provide siginfo_t information). > > My recommendation is not to use SIGIO and SIGURG at all. If you use > signal handlers, your program is very likely to suffer from race > condition problems unless you unmask the signal only at well-defined > safe points. If you use sigtimedwait() or similar, select()/poll() can > provide similar functionality. Alternatively, if you have many > descriptors to watch, use non-portable facilities like BSD kqueue, Linux > epoll, Solaris ports or portable wrappers around them. Realtime signals > are nasty for this -- the signal queue has a finite size and when it > overflows you need a "resync" step that is expensive both in CPU and > programmer time. > > -- > Jilles Tjoelker > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Fwd: my git development snapshot(s)
On (18/09/2011 12:14), Andriy Gapon wrote: > > Just decided to follow the global trends and trying to throw all of my > local/private changes at you in hope that the "crowd-sourcing magic" might > somehow happen :-) This seems definitely easier than carefully producing the > patch files and keeping them up-to-date. > > So, my newly cloned gitorious repository: > https://gitorious.org/~avg/freebsd/avgbsd > > And the first branch of interest: > https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 > > This is a snapshot of almost all of my local changes to the FreeBSD src tree. > Please note that the branch is not intended to be public in the git sense. > That > is, there will be no linear history - I periodically rebase my changes on top > of > the svn head and also frequently reshuffle/merge/split commits. > The snapshot is not tidied up, there are quite a few commits that should be > merged into other commits, some commit messages are not accurate/pretty, etc. > The older the commits, the more mature they are supposed to be. > > Based on the above, no new commits are expected to this snapshot branch. > I will produce new snapshot branches from time to time. > > I am posting this information to this list initially, later I plan to share > the > code with the wider audience e.g. via hackers@. > > P.S. This code sharing is made easier for me by git, Gitorious and "git rebase > --onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone > repository at Gitorious! Let me share my experience as well. My repo: https://github.com/glk/freebsd-head/ I used rebase to keep local branches as well, but no longer do so. Such setup worked for me at least for two years, I had local changes and worked on a larger patchset for 7,8-STABLE and CURRENT branches simultaneously (no longer do it either). But (imho) this approach his serious drawbacks. The biggest one is that it's hard to check if regression comes from your code or recently merged upstream code. The second one: once you screw rebase (merge) you are in big trouble. Both issues can be worked around by keeping previous master branches, but it hardly helps: once there are conflicts with upstream or your local changes get commited upstream it becomes only harder and harder. (I used to have master-prev-DATE similar to devel-DATE Andriy uses.) I like and use rebase a lot while working on the code: reorganize commits, small fixups, etc. But try not to touch code that is more than several days old unless really necessary. The reason is to maintain code base in well tested state: imagine you've changed or small bit in HEAD~20, a week later you find a bug, bisect to find that it showed up in orig-HEAD~10 because of your small fix in orig-HEAD~20. Fixing it would have taken less time without that rebase, or bug wouldn't appear in the first place. Once history stabilizes (i.e. remains untouched for 3-4 days) I push it public or backup (for local projects) repository. There is no history rewriting after this point. Use separate branches for independent patchsets. E.g. tmpfs branch - for tmpfs changes, misc - for smaller changes, etc. It lets me bisect and test code easier. For example if I get strange panic I could create temporal branch with all patchsets except pefs branch. Test it, find faulty branch, bisect individual changes. Besides it's also possible to bisect master branch, merge appropriate patchset revisions while bisecting upstream, etc. Upgrade procedure. Patchset branches are independently merged with upstream (vendor/master in my case). And all patchset branches are merged into master branch. In other words resolve conflicts in patchset branches, merge everything back to master. I usually merge individual branches only if there are conflicts or after important milestone. Octopus merge in git may not be as good as you I'd like it to if there are conflicts in several branches, but it's manageable. I also find identifying my changes vs upstream easier than in rebase scenario: - Use 'git log --first-parent'. Limiting number of commits to show in gitk is also good option for large repositories. - Use 'git merge --no-log --no-ff' to merge with upstream, it strips excessive logs from commit message, --no-ff is necessary only for the first time because fast-forward merges won't be possible. To keep history extremely clean: create empty git repo, make non-empty commit and merge with upstream. And there is hope that keeping independent branches would make "crowd-sourcing magic" more feasible :) I'd prefer to be able to merge code I'm interested in without touching unrelated bits. Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> Hi list, >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean >> >> that >> >> driver (and chip) do not support IP TX checksum offload or the support for >> >> TX is not yet included in the driver? > ... >> This is slightly off-topic, but still.. >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> has been implemented in the driver. As per the product brief, the > ... >> [0]: the commit message say "performance was not good", but it is not >> the driver's developer to decide whether or not a feature is good or >> not. The developer's job is to implement the chip capabilities, and >> let it to the user to enable or disable the capabilities. At best, the >> developer can decide whether or not to enable the feature by default. > > actually, this is a perfect example where the developer has done the > right thing: implemented the feature, verified that performance is bad, > hence presumably removed support for the feature from the code (which also > means that the normal code path will run faster because there are no > run-time decisions to be made). > > "optional" features are often costly even when disabled. > I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. Now I might also openly question the test method used by the folks at Intel, just seeing how much issue I've had with the driver (I still have for some, even if not driver related), which have not been reproduced there. Finally, when someone say "performance are better that way", the first thing I'd be tempted to ask is: "What is your test ? How did you collects the numbers ? How did you reach the conclusion ?". None of this stuff is public. regards, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> Hi list, > >> > >> The data sheet for intel 82576 advertises IP TX/RX checksum offload > >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean > >> that > >> driver (and chip) do not support IP TX checksum offload or the support for > >> TX is not yet included in the driver? ... > This is slightly off-topic, but still.. > > FWIW, I'm not really impressed by what chips claim to support vs. what > has been implemented in the driver. As per the product brief, the ... > [0]: the commit message say "performance was not good", but it is not > the driver's developer to decide whether or not a feature is good or > not. The developer's job is to implement the chip capabilities, and > let it to the user to enable or disable the capabilities. At best, the > developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). "optional" features are often costly even when disabled. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Mixing Asynchronous Network I/O and POSIX Threads
On Sun, Sep 18, 2011 at 11:32:08AM -0400, Richard Yao wrote: > I wrote a program for Linux that uses Asynchronous Network I/O and > POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to > specify which thread handles each connection's SIGIO interrupts. > gettid() is Linux-specific and I would prefer to do this in a way that > also works with FreeBSD. Is that possible? In FreeBSD, you can only F_SETOWN processes or process groups, not threads, so a direct port is probably not possible. Another Linux feature not in FreeBSD is F_SETSIG (to send a realtime signal instead of SIGIO and provide siginfo_t information). My recommendation is not to use SIGIO and SIGURG at all. If you use signal handlers, your program is very likely to suffer from race condition problems unless you unmask the signal only at well-defined safe points. If you use sigtimedwait() or similar, select()/poll() can provide similar functionality. Alternatively, if you have many descriptors to watch, use non-portable facilities like BSD kqueue, Linux epoll, Solaris ports or portable wrappers around them. Realtime signals are nasty for this -- the signal queue has a finite size and when it overflows you need a "resync" step that is expensive both in CPU and programmer time. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> Hi list, >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that >> driver (and chip) do not support IP TX checksum offload or the support for >> TX is not yet included in the driver? > > After reading this mail, I checked em(4)/lem(4) code and noticed > these drivers removed CSUM_IP capability as well. igb(4) didn't > support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage > of IP checksum offloading capability. > Given that these drivers share many code with Linux, Jack may know > the details and why IP checksum offloading code was removed. Note, > Linux does not use IP checksum offloading so I guess this could be > oversight in shared code. > > BTW, hackers may not be right ML to post this kind of post. > CCed to jfv@, the driver maintainer. > This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the 82574 supports multiqueue (at least should support up to 5 MSI-X vectors, 2 RX and 2 TX), but this support was removed from em(4) in mid-2010[0]. Also, the 82571 and the 82574 should also support header split, but this is currently only implemented in igb(4), not em(4). - Arnaud [0]: the commit message say "performance was not good", but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace in FreeBSD 7.2
On Sat, Sep 17, 2011 at 1:14 AM, Julian Elischer wrote: > > I' am not sure that user space dtrace suport was available in 7.2.. My > memory is that it came in 8.x but I'm not certain. Userland dtrace was merged to stable/8 shortly after 8.2 was released. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Mixing Asynchronous Network I/O and POSIX Threads
On 2011-09-18 17:32, Richard Yao wrote: Dear FreeBSD Community: I wrote a program for Linux that uses Asynchronous Network I/O and POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to specify which thread handles each connection's SIGIO interrupts. gettid() is Linux-specific and I would prefer to do this in a way that also works with FreeBSD. Is that possible? How about pthread_self() ? /Uffe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Mixing Asynchronous Network I/O and POSIX Threads
Dear FreeBSD Community: I wrote a program for Linux that uses Asynchronous Network I/O and POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to specify which thread handles each connection's SIGIO interrupts. gettid() is Linux-specific and I would prefer to do this in a way that also works with FreeBSD. Is that possible? I am not on the mailing list. Please CC me any responses. Yours truly, Richard Yao ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Fwd: my git development snapshot(s)
Just decided to follow the global trends and trying to throw all of my local/private changes at you in hope that the "crowd-sourcing magic" might somehow happen :-) This seems definitely easier than carefully producing the patch files and keeping them up-to-date. So, my newly cloned gitorious repository: https://gitorious.org/~avg/freebsd/avgbsd And the first branch of interest: https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 This is a snapshot of almost all of my local changes to the FreeBSD src tree. Please note that the branch is not intended to be public in the git sense. That is, there will be no linear history - I periodically rebase my changes on top of the svn head and also frequently reshuffle/merge/split commits. The snapshot is not tidied up, there are quite a few commits that should be merged into other commits, some commit messages are not accurate/pretty, etc. The older the commits, the more mature they are supposed to be. Based on the above, no new commits are expected to this snapshot branch. I will produce new snapshot branches from time to time. I am posting this information to this list initially, later I plan to share the code with the wider audience e.g. via hackers@. P.S. This code sharing is made easier for me by git, Gitorious and "git rebase --onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone repository at Gitorious! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
