Menu
▾
▴
tipc-discussion
|
From: Laser <got...@gm...> - 2009-04-24 17:13:36
Attachments:
Description of changes.txt
|
Hi, I have developed a workaround to support TIPC over VLAN interfaces. This would work for VLAN interfaces of the form vlan0,vlan1 etc but not for the form fei1.50,fei1.30 etc. The patch file and a description of changes are attached. The changes are done in the file tipc_eth_media.c. This fix was tested with Vxworks 6.3,TIPC 1.7.6. This fix was also tested against a linux unit running TIPC over VLAN interfaces. Kindly review the code and let me know your comments. Regards, laser On 3/25/09, Stephens, Allan <all...@wi...> wrote: > Hi Laser: > > I've looked into how VxWorks supports VLANs a bit more, and I think that > my suggestion to try using the "dot" notation for accessing the VLAN > interface was either incorrect or insufficient. Consequently, the fact > that ethBearerEnable() isn't parsing the VLAN info may or may not really > be a bug. > > Part of my confusion stems from the fact that VxWorks seems to provide > VLAN support in 3 different ways. It sounds like you're creating "a > pseudo-interface with which you can manage the VLAN as a subnet". > (Please let me know if this assumption is incorrect.) That being the > case, one sequence of steps for getting TIPC to work on a VLAN in > VxWorks should be the following: > > ifconfig "vlan0 create" > ifconfig "vlan0 vlan 20 vlanif <ifname>" > - where <ifname> is fei1 (or similar), > and which must have an IP address assigned to it > ifconfig "vlan0 <IPaddress>" > - where <IPaddress> is 190.0.2.123/24 (or similar), > and the main IP address part matches that of the parent interface > tipcConfig "-be=eth:vlan0" > > Unfortunately, I don't have a VLAN-capable VxWorks installation at hand > that I can experiment with, so I've no idea if this will really work. > If it doesn't, I recommend that you get in touch with Wind River support > to get help from someone who really understands the in's and out's of > using VLANs with VxWorks. > > A bit more info: > > VxWorks does seem to support the "dot" notation (at least it does in > VxWorks 6.6), which led to my previous suggestion. However, although > doing: > > ifconfig "fei1.20 create inet 190.0.2.123/24" > > will supposedly create an equivalent VLAN pseudo-interface, I've no idea > how TIPC is supposed to attach to it. The existing ethBearerEnable() > routine currently splits the interface name into 2 parts (eg. "fei" and > "1"), and passes them as separate arguments to muxTkBind(). I haven't > found any documentation describing how to bind to a "nameless" > pseudo-interface created using the "dot" notation. (For example, > splitting the name into "fei" and "1.20" won't work because the second > part is passed to muxTkBind() as an integer rather than a string.) > > -- Al > > >> -----Original Message----- >> From: Laser [mailto:got...@gm...] >> Sent: Wednesday, March 25, 2009 9:10 AM >> To: Stephens, Allan >> Cc: tipc-discussion >> Subject: Re: [tipc-discussion] Query regarding running TIPC >> over vlaninterfaces in Vxworks >> >> Hi Al, >> >> I created vlan interface vlan0, assigned vlan id 20, bound it >> to an ethernet interface and was able to enable bearer by >> using "tipc-config -be=eth:fei0.20". There were no >> issues.But I faced issue while enabling another existing vlan >> interface as a bearer. i.e "tipc-config -be=eth:fei0.5" >> resulted in "unable to enable bearer". >> Disabling the bearer over vlan interface with VID 20 and then >> enabling bearer over vlan interface with VID 5 worked. >> >> I had a look at ethBearerEnable in tipc_eth_media.c and it >> looks like the vlan id is not used while enabling a ethernet >> bearer. The function ethBearerEnable assumes that "the >> interfaces are written in alphabetical characters followed by >> a unit number". So the bearer name is parsed, the device name >> and unit number are retrived and the rest of the string is >> discarded. As a result both fei0.20 and fei0.5 will result in >> device name "fei" and unit number 0. These values are then >> passed to endFindByName(). >> >> I could establish TIPC session between two units with fei0.20 >> as bearer in first unit and fei0.30 as bearer in other unit. >> I checked the packet statistics in both units and found that >> the packet count for vlan interfaces are not increasing. >> >> This looks like a bug with TIPC configuration. >> >> Regards, >> Laser >> >> >> On 3/24/09, Stephens, Allan <all...@wi...> wrote: >> > Hi Laser: >> > >> > I haven't used VLANs with VxWorks before, but I have had a bit of >> > experience with Linux. If you've created "vlan0" by >> selecting VLAN 20 >> > of interface "fei0" (say), you might need to do "-be=eth:fei0.20" >> > rather than "-be=eth:vlan0". (The VxWorks 6.6 >> documentation I've got >> > in front of me seems to support doing things this way, but I'm not >> > sure that it applies to VxWorks 6.3, too ... there have been some >> > changes to the network stack in VxWorks in the last few releases.) >> > >> > Give it a try and let us know the result. >> > >> > Regards, >> > Al >> > >> >> -----Original Message----- >> >> From: Laser [mailto:got...@gm...] >> >> Sent: Tuesday, March 24, 2009 10:04 AM >> >> To: tipc-discussion >> >> Subject: Re: [tipc-discussion] Query regarding running TIPC over >> >> vlaninterfaces in Vxworks >> >> >> >> Hi, >> >> >> >> Btw I am running TIPC 1.7.6 over vxworks 6.3. >> >> >> >> Thanks in Advance. >> >> >> >> Regards, >> >> Laser >> >> >> >> On 3/24/09, Laser <got...@gm...> wrote: >> >> > Hi, >> >> > I am trying to enable a TIPC bearer over a vlan interface >> >> in Vxworks. >> >> > I am getting the error message "unable to enable bearer". >> >> > >> >> > The steps followed are, >> >> > 1) Interfaces vlan0 and vlan1 were created using >> ifconfig utility. >> >> > They were made members of vlans 20 and 30 respectively and >> >> bound over >> >> > an ethernet interface. >> >> > 2) The TIPC netid and the node id were configured using >> tipc-config >> >> > utility. >> >> > 3) Enabling of TIPC bearers over interfaces vlan0 and vlan1 >> >> were done >> >> > i.e. "tipc-config -be=eth:vlan0" and "tipc-config >> >> -be=eth:vlan1". This >> >> > step resulted in the error "unable to enable bearer". >> >> > >> >> > Am I missing something? >> >> > How could I enable TIPC bearers over the interfaces >> vlan0 and vlan1? >> >> > >> >> > Regards, >> >> > Laser >> >> > >> >> >> >> -------------------------------------------------------------- >> >> ---------------- >> >> Apps built with the Adobe(R) Flex(R) framework and Flex >> >> Builder(TM) are powering Web 2.0 with engaging, cross-platform >> >> capabilities. Quickly and easily build your RIAs with Flex >> Builder, >> >> the Eclipse(TM)based development software that enables intelligent >> >> coding and step-through debugging. >> >> Download the free 60 day trial. >> >> http://p.sf.net/sfu/www-adobe-com >> >> _______________________________________________ >> >> tipc-discussion mailing list >> >> tip...@li... >> >> https://lists.sourceforge.net/lists/listinfo/tipc-discussion >> >> >> > >> > |
|
From: Laser <got...@gm...> - 2009-04-24 17:24:14
Attachments:
Description of changes.txt
tipc_eth_media_patch.txt
|
Resending the mail with attachments as txt files. ---------- Forwarded message ---------- From: Laser <got...@gm...> Date: Fri, Apr 24, 2009 at 10:13 AM Subject: Re: [tipc-discussion] Query regarding running TIPC over vlaninterfaces in Vxworks - Patch Attached To: tip...@li... Cc: all...@wi... Hi, I have developed a workaround to support TIPC over VLAN interfaces. This would work for VLAN interfaces of the form vlan0,vlan1 etc but not for the form fei1.50,fei1.30 etc. The patch file and a description of changes are attached. The changes are done in the file tipc_eth_media.c. This fix was tested with Vxworks 6.3,TIPC 1.7.6. This fix was also tested against a linux unit running TIPC over VLAN interfaces. Kindly review the code and let me know your comments. Regards, laser On 3/25/09, Stephens, Allan <all...@wi...> wrote: > Hi Laser: > > I've looked into how VxWorks supports VLANs a bit more, and I think that > my suggestion to try using the "dot" notation for accessing the VLAN > interface was either incorrect or insufficient. Consequently, the fact > that ethBearerEnable() isn't parsing the VLAN info may or may not really > be a bug. > > Part of my confusion stems from the fact that VxWorks seems to provide > VLAN support in 3 different ways. It sounds like you're creating "a > pseudo-interface with which you can manage the VLAN as a subnet". > (Please let me know if this assumption is incorrect.) That being the > case, one sequence of steps for getting TIPC to work on a VLAN in > VxWorks should be the following: > > ifconfig "vlan0 create" > ifconfig "vlan0 vlan 20 vlanif <ifname>" > - where <ifname> is fei1 (or similar), > and which must have an IP address assigned to it > ifconfig "vlan0 <IPaddress>" > - where <IPaddress> is 190.0.2.123/24 (or similar), > and the main IP address part matches that of the parent interface > tipcConfig "-be=eth:vlan0" > > Unfortunately, I don't have a VLAN-capable VxWorks installation at hand > that I can experiment with, so I've no idea if this will really work. > If it doesn't, I recommend that you get in touch with Wind River support > to get help from someone who really understands the in's and out's of > using VLANs with VxWorks. > > A bit more info: > > VxWorks does seem to support the "dot" notation (at least it does in > VxWorks 6.6), which led to my previous suggestion. However, although > doing: > > ifconfig "fei1.20 create inet 190.0.2.123/24" > > will supposedly create an equivalent VLAN pseudo-interface, I've no idea > how TIPC is supposed to attach to it. The existing ethBearerEnable() > routine currently splits the interface name into 2 parts (eg. "fei" and > "1"), and passes them as separate arguments to muxTkBind(). I haven't > found any documentation describing how to bind to a "nameless" > pseudo-interface created using the "dot" notation. (For example, > splitting the name into "fei" and "1.20" won't work because the second > part is passed to muxTkBind() as an integer rather than a string.) > > -- Al > > >> -----Original Message----- >> From: Laser [mailto:got...@gm...] >> Sent: Wednesday, March 25, 2009 9:10 AM >> To: Stephens, Allan >> Cc: tipc-discussion >> Subject: Re: [tipc-discussion] Query regarding running TIPC >> over vlaninterfaces in Vxworks >> >> Hi Al, >> >> I created vlan interface vlan0, assigned vlan id 20, bound it >> to an ethernet interface and was able to enable bearer by >> using "tipc-config -be=eth:fei0.20". There were no >> issues.But I faced issue while enabling another existing vlan >> interface as a bearer. i.e "tipc-config -be=eth:fei0.5" >> resulted in "unable to enable bearer". >> Disabling the bearer over vlan interface with VID 20 and then >> enabling bearer over vlan interface with VID 5 worked. >> >> I had a look at ethBearerEnable in tipc_eth_media.c and it >> looks like the vlan id is not used while enabling a ethernet >> bearer. The function ethBearerEnable assumes that "the >> interfaces are written in alphabetical characters followed by >> a unit number". So the bearer name is parsed, the device name >> and unit number are retrived and the rest of the string is >> discarded. As a result both fei0.20 and fei0.5 will result in >> device name "fei" and unit number 0. These values are then >> passed to endFindByName(). >> >> I could establish TIPC session between two units with fei0.20 >> as bearer in first unit and fei0.30 as bearer in other unit. >> I checked the packet statistics in both units and found that >> the packet count for vlan interfaces are not increasing. >> >> This looks like a bug with TIPC configuration. >> >> Regards, >> Laser >> >> >> On 3/24/09, Stephens, Allan <all...@wi...> wrote: >> > Hi Laser: >> > >> > I haven't used VLANs with VxWorks before, but I have had a bit of >> > experience with Linux. If you've created "vlan0" by >> selecting VLAN 20 >> > of interface "fei0" (say), you might need to do "-be=eth:fei0.20" >> > rather than "-be=eth:vlan0". (The VxWorks 6.6 >> documentation I've got >> > in front of me seems to support doing things this way, but I'm not >> > sure that it applies to VxWorks 6.3, too ... there have been some >> > changes to the network stack in VxWorks in the last few releases.) >> > >> > Give it a try and let us know the result. >> > >> > Regards, >> > Al >> > >> >> -----Original Message----- >> >> From: Laser [mailto:got...@gm...] >> >> Sent: Tuesday, March 24, 2009 10:04 AM >> >> To: tipc-discussion >> >> Subject: Re: [tipc-discussion] Query regarding running TIPC over >> >> vlaninterfaces in Vxworks >> >> >> >> Hi, >> >> >> >> Btw I am running TIPC 1.7.6 over vxworks 6.3. >> >> >> >> Thanks in Advance. >> >> >> >> Regards, >> >> Laser >> >> >> >> On 3/24/09, Laser <got...@gm...> wrote: >> >> > Hi, >> >> > I am trying to enable a TIPC bearer over a vlan interface >> >> in Vxworks. >> >> > I am getting the error message "unable to enable bearer". >> >> > >> >> > The steps followed are, >> >> > 1) Interfaces vlan0 and vlan1 were created using >> ifconfig utility. >> >> > They were made members of vlans 20 and 30 respectively and >> >> bound over >> >> > an ethernet interface. >> >> > 2) The TIPC netid and the node id were configured using >> tipc-config >> >> > utility. >> >> > 3) Enabling of TIPC bearers over interfaces vlan0 and vlan1 >> >> were done >> >> > i.e. "tipc-config -be=eth:vlan0" and "tipc-config >> >> -be=eth:vlan1". This >> >> > step resulted in the error "unable to enable bearer". >> >> > >> >> > Am I missing something? >> >> > How could I enable TIPC bearers over the interfaces >> vlan0 and vlan1? >> >> > >> >> > Regards, >> >> > Laser >> >> > >> >> >> >> -------------------------------------------------------------- >> >> ---------------- >> >> Apps built with the Adobe(R) Flex(R) framework and Flex >> >> Builder(TM) are powering Web 2.0 with engaging, cross-platform >> >> capabilities. Quickly and easily build your RIAs with Flex >> Builder, >> >> the Eclipse(TM)based development software that enables intelligent >> >> coding and step-through debugging. >> >> Download the free 60 day trial. >> >> http://p.sf.net/sfu/www-adobe-com >> >> _______________________________________________ >> >> tipc-discussion mailing list >> >> tip...@li... >> >> https://lists.sourceforge.net/lists/listinfo/tipc-discussion >> >> >> > >> > |
|
From: Stephens, A. <all...@wi...> - 2009-05-05 18:28:59
|
Hi Laser: My apologies for the delay in reviewing your patch submission. It's been hard for me to find a large enough block of time in my schedule to look at an enhancement as complex as this one. My comments: - I'm not an expert in how VLAN code works in VxWorks, so I can't comment on the correctness of your analysis of the problem and your approach to solving it, but they both certainly seem to be quite reasonable. - The limitations you describe don't seem out of line with what TIPC does in other places, and are totally acceptable for an initial roll-out of VLAN support. - I don't like the way you've tried to make the "eth_bearers" array try to do "double duty" as a means to record info about TIPC bearers (both VLAN and standard ones) and Ethernet interfaces. (It made sense to do this when there was a one-to-one correspondence between each bearer and each interface, but that's no longer true.) I think things would be clearer if you created an "eth_interfaces" array, and put the interface-specific stuff (like the cookie returned by muxTkBind(), and a count of how many bearers were currently using the interface) in its entries. Admittedly, this means that enabling a bearer would require searching for a free slot in each array, rather than just one, but performance isn't critical here. On the other hard, I think you might get a performance saving in ethTipcRcvRtn() in the initial handling of untagged packets. It might also allow you to eliminate (or simplify) some of the routines you added at the end of the file. - The way ethVlanGetBearer() is currently locating the VLAN bearer is sub-optimial, because it requires the routine to do a string comparison (of the interface name) and a numeric comparison (of the VLAN id) for every single incoming VLAN packet the parent interface receives. (Actually, this is not quite true; you have included code that avoids this search in the case where only a single VLAN bearer is enabled on an interface, but things break down once a second VLAN bearer is used on the same interface.) It would be more efficient to search against a single numeric "key" consisting of an interface identifier (perhaps the array index of the associated "eth_interfaces" entry I suggested?) in the high order bits and the VLAN id in the low order (12?) bits. Minor quibbles: - line 138: I don't think the tipcBoolean type is needed. VxWorks defines "TRUE" and "FALSE" as 1 and 0 already, and I think it also defines "BOOL" as an equivalent to "int". (I realize that your code makes false equivalent to -1, rather than 0, so that other changes are needed to your algorithms; however, the current state of affairs is likely to cause confusion down the road. It certainly confused me!) - line 336: You might want to save the result of the VLAN-or-not-VLAN check so that you don't need to repeat it on line 372. - line 558: Initializing "ifName" to all zeros seems unnecessary, since it is never used without first being set to something else. (Also, a faster way to make it an empty string is to do "ifName[0] = '\0';".) - line 569: I think this check can be simplified to "if (strstr(name, "vlan") == name)" to avoid the call to strlen(); alternatively, you could just put in the value 4. - line 574: You should probably return -ENODEV here, rather than -EINVAL. All things considered, this looks like an excellent start at adding VLAN support for VxWorks TIPC. Please let me know if you have any questions about any of my comments, and feel free to send me an updated patch when you've got one. Regards, Al > -----Original Message----- > From: Laser [mailto:got...@gm...] > Sent: Friday, April 24, 2009 1:24 PM > To: tipc-discussion > Subject: [tipc-discussion] Fwd: Query regarding running TIPC > overvlaninterfaces in Vxworks - Patch Attached > > Resending the mail with attachments as txt files. > > ---------- Forwarded message ---------- > From: Laser <got...@gm...> > Date: Fri, Apr 24, 2009 at 10:13 AM > Subject: Re: [tipc-discussion] Query regarding running TIPC > over vlaninterfaces in Vxworks - Patch Attached > To: tip...@li... > Cc: all...@wi... > > > Hi, > > I have developed a workaround to support TIPC over VLAN interfaces. > This would work for VLAN interfaces of the form vlan0,vlan1 > etc but not for the form fei1.50,fei1.30 etc. > > The patch file and a description of changes are attached. The > changes are done in the file tipc_eth_media.c. This fix was > tested with Vxworks 6.3,TIPC 1.7.6. This fix was also tested > against a linux unit running TIPC over VLAN interfaces. > > Kindly review the code and let me know your comments. > > Regards, > laser > > > On 3/25/09, Stephens, Allan <all...@wi...> wrote: > > Hi Laser: > > > > I've looked into how VxWorks supports VLANs a bit more, and I think > > that my suggestion to try using the "dot" notation for > accessing the > > VLAN interface was either incorrect or insufficient. Consequently, > > the fact that ethBearerEnable() isn't parsing the VLAN info > may or may > > not really be a bug. > > > > Part of my confusion stems from the fact that VxWorks seems > to provide > > VLAN support in 3 different ways. It sounds like you're > creating "a > > pseudo-interface with which you can manage the VLAN as a subnet". > > (Please let me know if this assumption is incorrect.) That > being the > > case, one sequence of steps for getting TIPC to work on a VLAN in > > VxWorks should be the following: > > > > ifconfig "vlan0 create" > > ifconfig "vlan0 vlan 20 vlanif <ifname>" > > - where <ifname> is fei1 (or similar), > > and which must have an IP address assigned to it > ifconfig "vlan0 > > <IPaddress>" > > - where <IPaddress> is 190.0.2.123/24 (or similar), > > and the main IP address part matches that of the parent > interface > > tipcConfig "-be=eth:vlan0" > > > > Unfortunately, I don't have a VLAN-capable VxWorks installation at > > hand that I can experiment with, so I've no idea if this > will really work. > > If it doesn't, I recommend that you get in touch with Wind River > > support to get help from someone who really understands the > in's and > > out's of using VLANs with VxWorks. > > > > A bit more info: > > > > VxWorks does seem to support the "dot" notation (at least > it does in > > VxWorks 6.6), which led to my previous suggestion. > However, although > > doing: > > > > ifconfig "fei1.20 create inet 190.0.2.123/24" > > > > will supposedly create an equivalent VLAN pseudo-interface, I've no > > idea how TIPC is supposed to attach to it. The existing > > ethBearerEnable() routine currently splits the interface > name into 2 > > parts (eg. "fei" and "1"), and passes them as separate arguments to > > muxTkBind(). I haven't found any documentation describing > how to bind to a "nameless" > > pseudo-interface created using the "dot" notation. (For example, > > splitting the name into "fei" and "1.20" won't work because > the second > > part is passed to muxTkBind() as an integer rather than a string.) > > > > -- Al > > > > > >> -----Original Message----- > >> From: Laser [mailto:got...@gm...] > >> Sent: Wednesday, March 25, 2009 9:10 AM > >> To: Stephens, Allan > >> Cc: tipc-discussion > >> Subject: Re: [tipc-discussion] Query regarding running TIPC over > >> vlaninterfaces in Vxworks > >> > >> Hi Al, > >> > >> I created vlan interface vlan0, assigned vlan id 20, bound > it to an > >> ethernet interface and was able to enable bearer by using > >> "tipc-config -be=eth:fei0.20". There were no issues.But I faced > >> issue while enabling another existing vlan interface as a > bearer. i.e > >> "tipc-config -be=eth:fei0.5" > >> resulted in "unable to enable bearer". > >> Disabling the bearer over vlan interface with VID 20 and then > >> enabling bearer over vlan interface with VID 5 worked. > >> > >> I had a look at ethBearerEnable in tipc_eth_media.c and it > looks like > >> the vlan id is not used while enabling a ethernet bearer. The > >> function ethBearerEnable assumes that "the interfaces are > written in > >> alphabetical characters followed by a unit number". So the bearer > >> name is parsed, the device name and unit number are > retrived and the > >> rest of the string is discarded. As a result both fei0.20 > and fei0.5 > >> will result in device name "fei" and unit number 0. These > values are > >> then passed to endFindByName(). > >> > >> I could establish TIPC session between two units with fei0.20 as > >> bearer in first unit and fei0.30 as bearer in other unit. > >> I checked the packet statistics in both units and found that the > >> packet count for vlan interfaces are not increasing. > >> > >> This looks like a bug with TIPC configuration. > >> > >> Regards, > >> Laser > >> > >> > >> On 3/24/09, Stephens, Allan <all...@wi...> wrote: > >> > Hi Laser: > >> > > >> > I haven't used VLANs with VxWorks before, but I have had > a bit of > >> > experience with Linux. If you've created "vlan0" by > >> selecting VLAN 20 > >> > of interface "fei0" (say), you might need to do "-be=eth:fei0.20" > >> > rather than "-be=eth:vlan0". (The VxWorks 6.6 > >> documentation I've got > >> > in front of me seems to support doing things this way, > but I'm not > >> > sure that it applies to VxWorks 6.3, too ... there have > been some > >> > changes to the network stack in VxWorks in the last few > releases.) > >> > > >> > Give it a try and let us know the result. > >> > > >> > Regards, > >> > Al > >> > > >> >> -----Original Message----- > >> >> From: Laser [mailto:got...@gm...] > >> >> Sent: Tuesday, March 24, 2009 10:04 AM > >> >> To: tipc-discussion > >> >> Subject: Re: [tipc-discussion] Query regarding running > TIPC over > >> >> vlaninterfaces in Vxworks > >> >> > >> >> Hi, > >> >> > >> >> Btw I am running TIPC 1.7.6 over vxworks 6.3. > >> >> > >> >> Thanks in Advance. > >> >> > >> >> Regards, > >> >> Laser > >> >> > >> >> On 3/24/09, Laser <got...@gm...> wrote: > >> >> > Hi, > >> >> > I am trying to enable a TIPC bearer over a vlan interface > >> >> in Vxworks. > >> >> > I am getting the error message "unable to enable bearer". > >> >> > > >> >> > The steps followed are, > >> >> > 1) Interfaces vlan0 and vlan1 were created using > >> ifconfig utility. > >> >> > They were made members of vlans 20 and 30 respectively and > >> >> bound over > >> >> > an ethernet interface. > >> >> > 2) The TIPC netid and the node id were configured using > >> tipc-config > >> >> > utility. > >> >> > 3) Enabling of TIPC bearers over interfaces vlan0 and vlan1 > >> >> were done > >> >> > i.e. "tipc-config -be=eth:vlan0" and "tipc-config > >> >> -be=eth:vlan1". This > >> >> > step resulted in the error "unable to enable bearer". > >> >> > > >> >> > Am I missing something? > >> >> > How could I enable TIPC bearers over the interfaces > >> vlan0 and vlan1? > >> >> > > >> >> > Regards, > >> >> > Laser > >> >> > > >> >> > >> >> -------------------------------------------------------------- > >> >> ---------------- > >> >> Apps built with the Adobe(R) Flex(R) framework and Flex > >> >> Builder(TM) are powering Web 2.0 with engaging, cross-platform > >> >> capabilities. Quickly and easily build your RIAs with Flex > >> Builder, > >> >> the Eclipse(TM)based development software that enables > intelligent > >> >> coding and step-through debugging. > >> >> Download the free 60 day trial. > >> >> http://p.sf.net/sfu/www-adobe-com > >> >> _______________________________________________ > >> >> tipc-discussion mailing list > >> >> tip...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/tipc-discussion > >> >> > >> > > >> > > > |
|
From: Stephens, A. <all...@wi...> - 2009-05-11 16:12:13
|
Hi Laser: Understood. Thanks for developing your patch and posting it to the mailing list. With luck someone will pick up where you left off and finish the job at some point in the future, since the hardest part is already done ... Regards, Al > -----Original Message----- > From: Laser [mailto:got...@gm...] > Sent: Friday, May 08, 2009 10:52 PM > To: Stephens, Allan > Subject: Re: [tipc-discussion] Fwd: Query regarding running > TIPC overvlaninterfaces in Vxworks - Patch Attached > > Hi Al, > > Thanks a lot for your comments. > > We have moved into non TIPC part of our project and it was > decided to live with the current fix as of now. I am not sure > that I could provide an updated patch in near future. > > Thanks again. > > Regards, > Laser > > > On Tue, May 5, 2009 at 11:28 AM, Stephens, Allan > <all...@wi...> wrote: > > Hi Laser: > > > > My apologies for the delay in reviewing your patch > submission. It's been hard for me to find a large enough > block of time in my schedule to look at an enhancement as > complex as this one. > > > > My comments: > > > > - I'm not an expert in how VLAN code works in VxWorks, so I > can't comment on the correctness of your analysis of the > problem and your approach to solving it, but they both > certainly seem to be quite reasonable. > > > > - The limitations you describe don't seem out of line with > what TIPC does in other places, and are totally acceptable > for an initial roll-out of VLAN support. > > > > - I don't like the way you've tried to make the > "eth_bearers" array try to do "double duty" as a means to > record info about TIPC bearers (both VLAN and standard ones) > and Ethernet interfaces. (It made sense to do this when > there was a one-to-one correspondence between each bearer and > each interface, but that's no longer true.) I think things > would be clearer if you created an "eth_interfaces" array, > and put the interface-specific stuff (like the cookie > returned by muxTkBind(), and a count of how many bearers were > currently using the interface) in its entries. Admittedly, > this means that enabling a bearer would require searching for > a free slot in each array, rather than just one, but > performance isn't critical here. On the other hard, I think > you might get a performance saving in ethTipcRcvRtn() in the > initial handling of untagged packets. It might also allow > you to eliminate (or simplify) some of the routines you added > at the end of the file. > > > > - The way ethVlanGetBearer() is currently locating the VLAN > bearer is sub-optimial, because it requires the routine to do > a string comparison (of the interface name) and a numeric > comparison (of the VLAN id) for every single incoming VLAN > packet the parent interface receives. (Actually, this is not > quite true; you have included code that avoids this search in > the case where only a single VLAN bearer is enabled on an > interface, but things break down once a second VLAN bearer is > used on the same interface.) It would be more efficient to > search against a single numeric "key" consisting of an > interface identifier (perhaps the array index of the > associated "eth_interfaces" entry I suggested?) in the high > order bits and the VLAN id in the low order (12?) bits. > > > > Minor quibbles: > > > > - line 138: I don't think the tipcBoolean type is needed. VxWorks > > defines "TRUE" and "FALSE" as 1 and 0 already, and I think it also > > defines "BOOL" as an equivalent to "int". (I realize that > your code > > makes false equivalent to -1, rather than 0, so that other > changes are > > needed to your algorithms; however, the current state of affairs is > > likely to cause confusion down the road. It certainly confused me!) > > > > - line 336: You might want to save the result of the > VLAN-or-not-VLAN check so that you don't need to repeat it on > line 372. > > > > - line 558: Initializing "ifName" to all zeros seems unnecessary, > > since it is never used without first being set to something else. > > (Also, a faster way to make it an empty string is to do > "ifName[0] = > > '\0';".) > > > > - line 569: I think this check can be simplified to "if > (strstr(name, "vlan") == name)" to avoid the call to > strlen(); alternatively, you could just put in the value 4. > > > > - line 574: You should probably return -ENODEV here, rather > than -EINVAL. > > > > All things considered, this looks like an excellent start > at adding VLAN support for VxWorks TIPC. Please let me know > if you have any questions about any of my comments, and feel > free to send me an updated patch when you've got one. > > > > Regards, > > Al > > > >> -----Original Message----- > >> From: Laser [mailto:got...@gm...] > >> Sent: Friday, April 24, 2009 1:24 PM > >> To: tipc-discussion > >> Subject: [tipc-discussion] Fwd: Query regarding running TIPC > >> overvlaninterfaces in Vxworks - Patch Attached > >> > >> Resending the mail with attachments as txt files. > >> > >> ---------- Forwarded message ---------- > >> From: Laser <got...@gm...> > >> Date: Fri, Apr 24, 2009 at 10:13 AM > >> Subject: Re: [tipc-discussion] Query regarding running TIPC over > >> vlaninterfaces in Vxworks - Patch Attached > >> To: tip...@li... > >> Cc: all...@wi... > >> > >> > >> Hi, > >> > >> I have developed a workaround to support TIPC over VLAN interfaces. > >> This would work for VLAN interfaces of the form > vlan0,vlan1 etc but > >> not for the form fei1.50,fei1.30 etc. > >> > >> The patch file and a description of changes are attached. > The changes > >> are done in the file tipc_eth_media.c. This fix was tested with > >> Vxworks 6.3,TIPC 1.7.6. This fix was also tested against a > linux unit > >> running TIPC over VLAN interfaces. > >> > >> Kindly review the code and let me know your comments. > >> > >> Regards, > >> laser > >> > >> > >> On 3/25/09, Stephens, Allan <all...@wi...> wrote: > >> > Hi Laser: > >> > > >> > I've looked into how VxWorks supports VLANs a bit more, > and I think > >> > that my suggestion to try using the "dot" notation for > >> accessing the > >> > VLAN interface was either incorrect or insufficient. > Consequently, > >> > the fact that ethBearerEnable() isn't parsing the VLAN info > >> may or may > >> > not really be a bug. > >> > > >> > Part of my confusion stems from the fact that VxWorks seems > >> to provide > >> > VLAN support in 3 different ways. It sounds like you're > >> creating "a > >> > pseudo-interface with which you can manage the VLAN as a subnet". > >> > (Please let me know if this assumption is incorrect.) That > >> being the > >> > case, one sequence of steps for getting TIPC to work on > a VLAN in > >> > VxWorks should be the following: > >> > > >> > ifconfig "vlan0 create" > >> > ifconfig "vlan0 vlan 20 vlanif <ifname>" > >> > - where <ifname> is fei1 (or similar), > >> > and which must have an IP address assigned to it > >> ifconfig "vlan0 > >> > <IPaddress>" > >> > - where <IPaddress> is 190.0.2.123/24 (or similar), > >> > and the main IP address part matches that of the parent > >> interface > >> > tipcConfig "-be=eth:vlan0" > >> > > >> > Unfortunately, I don't have a VLAN-capable VxWorks > installation at > >> > hand that I can experiment with, so I've no idea if this > >> will really work. > >> > If it doesn't, I recommend that you get in touch with Wind River > >> > support to get help from someone who really understands the > >> in's and > >> > out's of using VLANs with VxWorks. > >> > > >> > A bit more info: > >> > > >> > VxWorks does seem to support the "dot" notation (at least > >> it does in > >> > VxWorks 6.6), which led to my previous suggestion. > >> However, although > >> > doing: > >> > > >> > ifconfig "fei1.20 create inet 190.0.2.123/24" > >> > > >> > will supposedly create an equivalent VLAN > pseudo-interface, I've no > >> > idea how TIPC is supposed to attach to it. The existing > >> > ethBearerEnable() routine currently splits the interface > >> name into 2 > >> > parts (eg. "fei" and "1"), and passes them as separate > arguments to > >> > muxTkBind(). I haven't found any documentation describing > >> how to bind to a "nameless" > >> > pseudo-interface created using the "dot" notation. (For > example, > >> > splitting the name into "fei" and "1.20" won't work because > >> the second > >> > part is passed to muxTkBind() as an integer rather than > a string.) > >> > > >> > -- Al > >> > > >> > > >> >> -----Original Message----- > >> >> From: Laser [mailto:got...@gm...] > >> >> Sent: Wednesday, March 25, 2009 9:10 AM > >> >> To: Stephens, Allan > >> >> Cc: tipc-discussion > >> >> Subject: Re: [tipc-discussion] Query regarding running > TIPC over > >> >> vlaninterfaces in Vxworks > >> >> > >> >> Hi Al, > >> >> > >> >> I created vlan interface vlan0, assigned vlan id 20, bound > >> it to an > >> >> ethernet interface and was able to enable bearer by using > >> >> "tipc-config -be=eth:fei0.20". There were no > issues.But I faced > >> >> issue while enabling another existing vlan interface as a > >> bearer. i.e > >> >> "tipc-config -be=eth:fei0.5" > >> >> resulted in "unable to enable bearer". > >> >> Disabling the bearer over vlan interface with VID 20 and then > >> >> enabling bearer over vlan interface with VID 5 worked. > >> >> > >> >> I had a look at ethBearerEnable in tipc_eth_media.c and it > >> looks like > >> >> the vlan id is not used while enabling a ethernet bearer. The > >> >> function ethBearerEnable assumes that "the interfaces are > >> written in > >> >> alphabetical characters followed by a unit number". So > the bearer > >> >> name is parsed, the device name and unit number are > >> retrived and the > >> >> rest of the string is discarded. As a result both fei0.20 > >> and fei0.5 > >> >> will result in device name "fei" and unit number 0. These > >> values are > >> >> then passed to endFindByName(). > >> >> > >> >> I could establish TIPC session between two units with > fei0.20 as > >> >> bearer in first unit and fei0.30 as bearer in other unit. > >> >> I checked the packet statistics in both units and found > that the > >> >> packet count for vlan interfaces are not increasing. > >> >> > >> >> This looks like a bug with TIPC configuration. > >> >> > >> >> Regards, > >> >> Laser > >> >> > >> >> > >> >> On 3/24/09, Stephens, Allan > <all...@wi...> wrote: > >> >> > Hi Laser: > >> >> > > >> >> > I haven't used VLANs with VxWorks before, but I have had > >> a bit of > >> >> > experience with Linux. If you've created "vlan0" by > >> >> selecting VLAN 20 > >> >> > of interface "fei0" (say), you might need to do > "-be=eth:fei0.20" > >> >> > rather than "-be=eth:vlan0". (The VxWorks 6.6 > >> >> documentation I've got > >> >> > in front of me seems to support doing things this way, > >> but I'm not > >> >> > sure that it applies to VxWorks 6.3, too ... there have > >> been some > >> >> > changes to the network stack in VxWorks in the last few > >> releases.) > >> >> > > >> >> > Give it a try and let us know the result. > >> >> > > >> >> > Regards, > >> >> > Al > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Laser [mailto:got...@gm...] > >> >> >> Sent: Tuesday, March 24, 2009 10:04 AM > >> >> >> To: tipc-discussion > >> >> >> Subject: Re: [tipc-discussion] Query regarding running > >> TIPC over > >> >> >> vlaninterfaces in Vxworks > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> Btw I am running TIPC 1.7.6 over vxworks 6.3. > >> >> >> > >> >> >> Thanks in Advance. > >> >> >> > >> >> >> Regards, > >> >> >> Laser > >> >> >> > >> >> >> On 3/24/09, Laser <got...@gm...> wrote: > >> >> >> > Hi, > >> >> >> > I am trying to enable a TIPC bearer over a vlan interface > >> >> >> in Vxworks. > >> >> >> > I am getting the error message "unable to enable bearer". > >> >> >> > > >> >> >> > The steps followed are, > >> >> >> > 1) Interfaces vlan0 and vlan1 were created using > >> >> ifconfig utility. > >> >> >> > They were made members of vlans 20 and 30 respectively and > >> >> >> bound over > >> >> >> > an ethernet interface. > >> >> >> > 2) The TIPC netid and the node id were configured using > >> >> tipc-config > >> >> >> > utility. > >> >> >> > 3) Enabling of TIPC bearers over interfaces vlan0 and vlan1 > >> >> >> were done > >> >> >> > i.e. "tipc-config -be=eth:vlan0" and "tipc-config > >> >> >> -be=eth:vlan1". This > >> >> >> > step resulted in the error "unable to enable bearer". > >> >> >> > > >> >> >> > Am I missing something? > >> >> >> > How could I enable TIPC bearers over the interfaces > >> >> vlan0 and vlan1? > >> >> >> > > >> >> >> > Regards, > >> >> >> > Laser > >> >> >> > > >> >> >> > >> >> >> > -------------------------------------------------------------- > >> >> >> ---------------- > >> >> >> Apps built with the Adobe(R) Flex(R) framework and Flex > >> >> >> Builder(TM) are powering Web 2.0 with engaging, > cross-platform > >> >> >> capabilities. Quickly and easily build your RIAs with Flex > >> >> Builder, > >> >> >> the Eclipse(TM)based development software that enables > >> intelligent > >> >> >> coding and step-through debugging. > >> >> >> Download the free 60 day trial. > >> >> >> http://p.sf.net/sfu/www-adobe-com > >> >> >> _______________________________________________ > >> >> >> tipc-discussion mailing list > >> >> >> tip...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/tipc-discussion > >> >> >> > >> >> > > >> >> > >> > > >> > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X