Re: RFC: Enabling VIMAGE in GENERIC

[Julian Elischer]

On 12/2/14, 7:31 PM, Bjoern A. Zeeb wrote:

On 30 Nov 2014, at 10:04 , Julian Elischer  wrote:


On 11/29/14, 5:28 PM, Craig Rodrigues wrote:

On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer mailto:jul...@freebsd.org>> wrote:


also look at the following: (a little dated)

http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22


This is a useful document.  I put it on the wiki: 
https://wiki.freebsd.org/VIMAGE/porting-to-vimage

Thanks.. wow, did I actually know ALL that only 5 years ago?
Scary.  probbaly worth having someone who is currently active and up to date 
look at it to see if it's all still correct..
especially the module load/unload stuff.

Yeah I popped it up in a browser window to read through it once I have a short 
break to do that.
thanks.. I remember learning most of that stuff the hard way.  but 
kids and work have pretty much made me forget it again and it may have 
gotten out of date.




—
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

[Bjoern A. Zeeb]

On 30 Nov 2014, at 10:04 , Julian Elischer  wrote:

> On 11/29/14, 5:28 PM, Craig Rodrigues wrote:
>> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > > wrote:
>> >
>> >
>> > also look at the following: (a little dated)
>> >
>> > http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22
>> 
>> 
>> This is a useful document.  I put it on the wiki: 
>> https://wiki.freebsd.org/VIMAGE/porting-to-vimage
> 
> Thanks.. wow, did I actually know ALL that only 5 years ago?
> Scary.  probbaly worth having someone who is currently active and up to date 
> look at it to see if it's all still correct..
> especially the module load/unload stuff.

Yeah I popped it up in a browser window to read through it once I have a short 
break to do that.

— 
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

[Julian Elischer]

On 11/29/14, 5:28 PM, Craig Rodrigues wrote:
On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > wrote:

>
>
> also look at the following: (a little dated)
>
> 
http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22



 This is a useful document.  I put it on the wiki: 
https://wiki.freebsd.org/VIMAGE/porting-to-vimage


Thanks.. wow, did I actually know ALL that only 5 years ago?
Scary.  probbaly worth having someone who is currently active and up 
to date look at it to see if it's all still correct..

especially the module load/unload stuff.



--
Craig


___
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

[Craig Rodrigues]

On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer  wrote:
>
>
> also look at the following: (a little dated)
>
>
http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22


 This is a useful document.  I put it on the wiki:
https://wiki.freebsd.org/VIMAGE/porting-to-vimage

--
Craig
___
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

[Julian Elischer]

On 11/20/14, 8:33 AM, Bjoern A. Zeeb wrote:

On 19 Nov 2014, at 23:14 , Craig Rodrigues  wrote:


On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney  wrote:


Yes, we need a man page talking about this feature first, how to enable
it, compile it into the kernel, how to manage it, what subsystems it
interacts w/, what sysctl nodes it provides, etc.


Marko,

Do you have any text which can be put into a vnet(9) man page?
It doesn't have to be perfect, but just something that we can start from.

I tried looking at some of the notes and presentations that you have done
on VIMAGE:
https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles

but didn’t see anything that could be readily turned into a man page.


https://people.freebsd.org/~bz/20100530-02.vnet.9.html

The man page should be in that perforce branch you converted to github.


also look at the following: (a little dated)

http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22


—
Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983

___
freebsd-a...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org"




___
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

[Craig Rodrigues]

On Wed, Nov 19, 2014 at 4:33 PM, Bjoern A. Zeeb  wrote:

>
>
> https://people.freebsd.org/~bz/20100530-02.vnet.9.html
>
> The man page should be in that perforce branch you converted to github.
>


Thank you for pointing that out.  It is indeed in github:
https://github.com/rodrigc/bz-vimage/tree/master/share/man/man9

I committed it to HEAD:
https://lists.freebsd.org/pipermail/svn-src-all/2014-November/095037.html

I used the textproc/igor port ( http://www.wonkity.com/~wblock/igor/ ) to
check the syntax of the man page.
It's a great new utility written by wblock@ and I encourage anyone creating
or modifying man pages should
run it.

--
Craig
___
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

[Bjoern A. Zeeb]

On 19 Nov 2014, at 23:14 , Craig Rodrigues  wrote:

> On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney  wrote:
> 
>> 
>> Yes, we need a man page talking about this feature first, how to enable
>> it, compile it into the kernel, how to manage it, what subsystems it
>> interacts w/, what sysctl nodes it provides, etc.
>> 
> 
> Marko,
> 
> Do you have any text which can be put into a vnet(9) man page?
> It doesn't have to be perfect, but just something that we can start from.
> 
> I tried looking at some of the notes and presentations that you have done
> on VIMAGE:
> https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles
> 
> but didn’t see anything that could be readily turned into a man page.


https://people.freebsd.org/~bz/20100530-02.vnet.9.html

The man page should be in that perforce branch you converted to github.


— 
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

[Craig Rodrigues]

On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney  wrote:

>
> Yes, we need a man page talking about this feature first, how to enable
> it, compile it into the kernel, how to manage it, what subsystems it
> interacts w/, what sysctl nodes it provides, etc.
>

Marko,

Do you have any text which can be put into a vnet(9) man page?
It doesn't have to be perfect, but just something that we can start from.

I tried looking at some of the notes and presentations that you have done
on VIMAGE:
https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles

but didn't see anything that could be readily turned into a man page.

--
Craig
___
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

[John-Mark Gurney]

Alexander V. Chernikov wrote this message on Wed, Nov 19, 2014 at 16:07 +0400:
> Can we have some wiki/man/docs on how particular subsystem should 
> interact with VNET first?

Yes, we need a man page talking about this feature first, how to enable
it, compile it into the kernel, how to manage it, what subsystems it
interacts w/, what sysctl nodes it provides, etc.

W/o man page(s) the feature is not complete.

$ man -k vnet
revnetgroup(8)   - generate reverse netgroup data
$ man -k vimage
XvCreateImage(3), XvShmCreateImage(3) - create an XvImage
XvPutImage(3), XvShmPutImage(3) - display an XvImage

hmm.. nope...  jail has something about vnets, but not nearly enough
to be useful...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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

[Bjoern A. Zeeb]

On 19 Nov 2014, at 03:28 , Craig Rodrigues  wrote:

> 
> (6)  Ask clusteradm to run one of the machines they use
>  for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
>  feedback.

For people to use pf with VIMAGE we first MUST have the security fix imported 
that I pointed out a couple of times in the past.

It won’t matter on the firewalls with just a VIMAGE enabled kernel but using 
VIMAGE + pf inside a jail (once that really works if it doesn’t already) will 
allow everyone how can administer pf inside the jail to take over the entire 
machine otherwise.

— 
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

[Marko Zec]

On Wed, 19 Nov 2014 16:07:46 +0400
"Alexander V. Chernikov"  wrote:
...
> Can we have some wiki/man/docs on how particular subsystem should 
> interact with VNET first?
> This can probably help to make proper vnet fixes in less number of 
> attempts :)
>
> For example, even attach/detach is handled differently in different
> places:
> 
> tcp_subr.c:
>  /* Skip initialization of globals for non-default instances.
> */ if (!IS_DEFAULT_VNET(curvnet))
>  return;
> in6_rmx.c:
> /*
>   * Initialize our routing tree.
>   */
> static VNET_DEFINE(int, _in6_rt_was_here);
> #define V__in6_rt_was_here  VNET(_in6_rt_was_here)
> 
>  if (V__in6_rtwas_here == 0) {
>  callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
>  in6_mtutimo(curvnet);   /* kick off timeout first
> time */ V__in6_rt_was_here = 1;
>  }
> 
>  return (1);
> }
> 
> It would be great to get a bit more details on the following (at
> least from my point of view):
> * what is the proper procedure of handling non-default VNET 
> attach/detach (locking mostly)

In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to
invoke per-subsystem ctors / dtors on per-vnet basis.

> * how can one properly cache needed VNET context (e.g. is it safe
> just to save "struct vnet *" pointer) and is this right thing to do
> at all?

Caching a VNET context should be avoided, as it yields similar problems
as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs
which may disappear by the time the mbuf gets dequeued.

> * Is it safe to to CURVNET_SET without holding any VNET locks ?

Yes, if the VNET context is derived from some of the arguments in the
current call graph.

> P.S. I'm not against VIMAGE in any kind, I think we really should
> move forward towards making it stable.
> However, "just turn it on" concept with a bunch of known (and
> unresolved issues) is not the best thing IMO.
> >
> > We have about 1 year until 11-RELEASE, so I think it is OK to do
> > this.
> >
> > I would also add two items to my action plan.
> >
> >
> > (6)  Ask clusteradm to run one of the machines they use
> >for PF firewalls + IPv6 with a VIMAGE enabled kernel, and
> > provide feedback.
> >
> > (7)  Ask for help with testing from companies who have more
> > involvement with the network stack.  Two of the people in the CC:
> > line of this e-mail work for such places. :)
> >
> > --
> > Craig
> >
> >
> > --
> > Craig
> > ___
> > 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"
> >
> 
> ___
> freebsd-virtualizat...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscr...@freebsd.org"

___
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

[Alexander V. Chernikov]

On 19.11.2014 07:28, Craig Rodrigues wrote:

On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein 
wrote:


On 11/17/14, 3:02 AM, Warner Losh wrote:


On Nov 17, 2014, at 12:46 AM, Craig Rodrigues 
wrote:



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


Yes, I agree with Alfred that we can turn VIMAGE back off before
11-RELEASE if things don't get cleaned up.
We have approximately until the end of 2015, so that gives
us time.






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



Again, I agree with Alfred on this.  Darren Reed originally imported
ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a
while.  Cy Schubert has recently expressed interest in ipfilter and has
committed some fixes in the past year, but has not fixed the VIMAGE problems
( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ).
I can take an initial effort at trying to fix VIMAGE + ipfilter.
In the past, I've delved into areas I'm not so familiar with in
order to fix VIMAGE + Bluetooth.  If Cy can provide any knowledge or
guidance, that will be great.

A lot of bug fixes have gone into VIMAGE in the past 2 years,
and I have received multiple reports of people using it in production
environments.  See the latest post by Peter Ross.

To flush out the last few issues and corner cases, I think we
need to turn VIMAGE on by default and get feedback and help from
the FreeBSD user community and developers to identify and fix the problems.
Can we have some wiki/man/docs on how particular subsystem should 
interact with VNET first?
This can probably help to make proper vnet fixes in less number of 
attempts :)


For example, even attach/detach is handled differently in different places:

tcp_subr.c:
/* Skip initialization of globals for non-default instances. */
if (!IS_DEFAULT_VNET(curvnet))
return;
in6_rmx.c:
/*
 * Initialize our routing tree.
 */
static VNET_DEFINE(int, _in6_rt_was_here);
#define V__in6_rt_was_here  VNET(_in6_rt_was_here)

if (V__in6_rtwas_here == 0) {
callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
in6_mtutimo(curvnet);   /* kick off timeout first time */
V__in6_rt_was_here = 1;
}

return (1);
}

It would be great to get a bit more details on the following (at least 
from my point of view):
* what is the proper procedure of handling non-default VNET 
attach/detach (locking mostly)
* how can one properly cache needed VNET context (e.g. is it safe just 
to save "struct vnet *" pointer) and is this right thing to do at all?

* Is it safe to to CURVNET_SET without holding any VNET locks ?


P.S. I'm not against VIMAGE in any kind, I think we really should move 
forward towards making it stable.
However, "just turn it on" concept with a bunch of known (and unresolved 
issues) is not the best thing IMO.


We have about 1 year until 11-RELEASE, so I think it is OK to do this.

I would also add two items to my action plan.


(6)  Ask clusteradm to run one of the machines they use
   for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
   feedback.

(7)  Ask for help with testing from companies who have more involvement
   with the network stack.  Two of the people in the CC: line of this
   e-mail work for such places. :)

--
Craig


--
Craig
___
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"



___
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

[Craig Rodrigues]

On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein 
wrote:

>
> On 11/17/14, 3:02 AM, Warner Losh wrote:
>
>> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues 
>> wrote:
>>
>>
>>> (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.
>

Yes, I agree with Alfred that we can turn VIMAGE back off before
11-RELEASE if things don't get cleaned up.
We have approximately until the end of 2015, so that gives
us time.



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


Again, I agree with Alfred on this.  Darren Reed originally imported
ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a
while.  Cy Schubert has recently expressed interest in ipfilter and has
committed some fixes in the past year, but has not fixed the VIMAGE problems
( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ).
I can take an initial effort at trying to fix VIMAGE + ipfilter.
In the past, I've delved into areas I'm not so familiar with in
order to fix VIMAGE + Bluetooth.  If Cy can provide any knowledge or
guidance, that will be great.

A lot of bug fixes have gone into VIMAGE in the past 2 years,
and I have received multiple reports of people using it in production
environments.  See the latest post by Peter Ross.

To flush out the last few issues and corner cases, I think we
need to turn VIMAGE on by default and get feedback and help from
the FreeBSD user community and developers to identify and fix the problems.

We have about 1 year until 11-RELEASE, so I think it is OK to do this.

I would also add two items to my action plan.


(6)  Ask clusteradm to run one of the machines they use
  for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
  feedback.

(7)  Ask for help with testing from companies who have more involvement
  with the network stack.  Two of the people in the CC: line of this
  e-mail work for such places. :)

--
Craig


--
Craig
___
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

[Peter Ross]

On Sun, 16 Nov 2014, Craig Rodrigues wrote:


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


I am using jails and VIMAGE for ca. 4 years, btw.

On the other side of the fence (see Linux) containers became quite popular with 
Docker and are also used for process management and separation (systemd e.g.)


Just to add this as a motivation for using jails and possibly VIMAGE, from a 
sysadmin perspective.


Regards
Peter
___
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]

Op 17 nov. 2014 om 16:37 heeft Dag-Erling Smørgrav  het volgende 
geschreven:

> Willem Jan Withagen  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"

Re: RFC: Enabling VIMAGE in GENERIC

[Alfred Perlstein]

On 11/17/14, 3:02 AM, Warner Losh wrote:

On Nov 17, 2014, at 12:46 AM, Craig Rodrigues  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"  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

[Dag-Erling Smørgrav]

Willem Jan Withagen  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

[Willem Jan Withagen]

On 17-11-2014 12:42, Bjoern A. Zeeb wrote:
> On 17 Nov 2014, at 11:20 , Willem Jan Withagen  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

[Bjoern A. Zeeb]

On 17 Nov 2014, at 11:20 , Willem Jan Withagen  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

[Willem Jan Withagen]

On 17-11-2014 12:02, Warner Losh wrote:
> 
> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues 
> 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"  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

[Warner Losh]

On Nov 17, 2014, at 12:46 AM, Craig Rodrigues  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"  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