Re: RFC: Enabling VIMAGE in GENERIC
On Nov 17, 2014, at 12:46 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, PROPOSAL == I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH == Index: sys/conf/NOTES === --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +optionsVIMAGE +optionsVNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly wishmaster artem...@ukr.net have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN === (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. And if these don’t get cleaned up? (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. And if this doesn’t happen? (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I don’t see that in the action plan. Without it, we’re enabling an option that has know, serious issue making 11 potentially a more unstable release. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFC: Enabling VIMAGE in GENERIC
On 17-11-2014 12:02, Warner Losh wrote: On Nov 17, 2014, at 12:46 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, PROPOSAL == I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH == Index: sys/conf/NOTES === --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +optionsVIMAGE +options VNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly wishmaster artem...@ukr.net have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN === (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. And if these don’t get cleaned up? (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. And if this doesn’t happen? (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I don’t see that in the action plan. Without it, we’re enabling an option that has know, serious issue making 11 potentially a more unstable release. Hi Warner, I think I understand your critique, but then on the other hand I wonder where the reluctance is As I read it, things are going to be enabled in CURRENT only (for the time). Which is exactly for the reasons you worry about: Is it going to be reliable enough?? But for that it needs exposure... So I would expect it to be turned off as a default IF things are not in a stable state that warrants a default enabling of the options. Things need to move forward, and taking this step is going to be required.. Otherwise I see a big risk of bit-rot somewhere down in the dungeons. --Willem Jan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC: Enabling VIMAGE in GENERIC
On 17 Nov 2014, at 11:20 , Willem Jan Withagen w...@digiware.nl wrote: I think I understand your critique, but then on the other hand I wonder where the reluctance is As I read it, things are going to be enabled in CURRENT only (for the time). Which is exactly for the reasons you worry about: Is it going to be reliable enough?? No, the answer to that still is “no” in it’s current state and we know that. I think one of the main problems is that no one has been able to pull the thing to the end in the last three years. Why should it happen within 6 weeks now? I think it would be a really good idea to do that but the current TODO list, I think, is by far not sufficing. There’s a second problem we’ll hit in that same timeframe: general network stack breakage; we’ll hit the times when we’ll not be sure if things broke because of VIMAGE or are also broken in the normal network stack. There’ll be a lot of regression test writing and debugging to be done. That all said, I’d like to see it happen as well, but I’d love to have a lot of the issues being addressed first before putting a date on it to enable it in GENERIC in HEAD. /bz — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC: Enabling VIMAGE in GENERIC
On 17-11-2014 12:42, Bjoern A. Zeeb wrote: On 17 Nov 2014, at 11:20 , Willem Jan Withagen w...@digiware.nl wrote: I think I understand your critique, but then on the other hand I wonder where the reluctance is As I read it, things are going to be enabled in CURRENT only (for the time). Which is exactly for the reasons you worry about: Is it going to be reliable enough?? No, the answer to that still is “no” in it’s current state and we know that. I think one of the main problems is that no one has been able to pull the thing to the end in the last three years. Why should it happen within 6 weeks now? I think it would be a really good idea to do that but the current TODO list, I think, is by far not sufficing. There’s a second problem we’ll hit in that same timeframe: general network stack breakage; we’ll hit the times when we’ll not be sure if things broke because of VIMAGE or are also broken in the normal network stack. There’ll be a lot of regression test writing and debugging to be done. That all said, I’d like to see it happen as well, but I’d love to have a lot of the issues being addressed first before putting a date on it to enable it in GENERIC in HEAD. Hi Bjoern, The constraints as you put them are indeed rather tight. There is little to be done about it. I was not aware of the fact that 11.0 is planned for release in such short time. Somewhere in the back op my head is: planning is start release cycle around Q2 2015. And I took the liberty to add some testing QA time to that, so I expect it after summer holidays in 2015. Now I admit: I don't write code for this, nor do I have the knowledge to so. But do run CURRENT to test exactly all these visualization options... Have not (yet) found a requirement to put VIMAGE to good use, so I never switched it on. The down side of all this, is that if we cannot turn it on during the 11-STABLE lifetime. Then it is going to take a full version release cycle to make it to the front. Which I find a pity, since it misses the opportunity for FreeBSD to add another distinctive element to their visualization possibilities. I prefer not to take this into a debate about the way things should go. Over time I've seen too many of these discussions turn in to shouting wars/bikesheds/and what not So given the fact I'm not going to do it, I'll leave the rest of the discussion to those that are actual doing all the work... (for which already 20 year of thanks) --WjW ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC: Enabling VIMAGE in GENERIC
Willem Jan Withagen w...@digiware.nl writes: The constraints as you put them are indeed rather tight. There is little to be done about it. I was not aware of the fact that 11.0 is planned for release in such short time. It isn't. ISTR that the target is 2015Q4. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC: Enabling VIMAGE in GENERIC
On 11/17/14, 3:02 AM, Warner Losh wrote: On Nov 17, 2014, at 12:46 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, PROPOSAL == I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH == Index: sys/conf/NOTES === --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +optionsVIMAGE +optionsVNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly wishmaster artem...@ukr.net have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN === (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. And if these don’t get cleaned up? If they are not cleaned/stable up by 11-RELEASE then we turn it off. That is simple. (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. And if this doesn’t happen? Well we do have 2 other firewalls in the kernel to pick, but we do need VIMAGE so I will let you draw your own conclusions. -Alfred ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: RFC: Enabling VIMAGE in GENERIC
Op 17 nov. 2014 om 16:37 heeft Dag-Erling Smørgrav d...@des.no het volgende geschreven: Willem Jan Withagen w...@digiware.nl writes: The constraints as you put them are indeed rather tight. There is little to be done about it. I was not aware of the fact that 11.0 is planned for release in such short time. It isn't. ISTR that the target is 2015Q4. So even further in the future than what I expected. But still, somebody(tm) needs to do the actual work. So they get the say. --WjW ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
